Understanding The Importance Of Unifying Your Cyber & Software Development Teams

 

In yesterday’s blog, I went into some detail as to how Cybersecurity is an integral part of the SDLC model, and the importance of software development teams to embrace this fact.  But even if some of eh suggestions are actually put into practice, there is still one problem left:  Getting along with the IT Security team. 

Unfortunately, both still work in their own worlds, and hardly ever share anything with each other.

The developers are heads down immersed in writing and compiling source code for the web application that they are trying to build, and of course, the IT Security team is just trying to keep up with what should have been done yesterday.  So how do you bring these two disparaging worlds together?  Here are some ideas:

1)     Just don’t put everything into a Word doc:

IT Security teams are known for being rather cold and unfeeling at times.  Rather than communicating what they think is going on, they merely put all of the vulnerabilities and gaps that they have discovered into a bullet format, and expect the other party to act on quickly, with a sense of urgency.  Unfortunately, for other departments that are not in the world of IT, people will take offense to this very quickly.  And very often, especially the software development will have no clue about what that document means.  Because of that, there will be pushback, and whatever the IT Security team wants will be put into the backburner.  So to avoid this precarious situation, list the items out in non-techno jargon sense, and put in a friendly, polite CTA.  And always put your contact info in case somebody needs to get a hold of you for questions and/or clarification.

2)     Keep whatever you want done simple:

It is a known fact that Cyber vendors love to go into a lot of detail explaining how to fix a problem. It’s just not our nature, and we are passionate in what we do. The bottom line is that we just want to help people.  But not everybody takes the same approach that we do.  Other people, especially your software developers, are busy folks themselves, and don’t have time to read a 10-page document of what needs to be fixed.  Instead, your best bet would be to put those into bulleted items, once again free from techno jargon, so that it can be read and understood quickly.  In other words, just tell your development team what needs to be fixed in the source code, and the best way for fixing it.  Also, to build a sense team spirit, ask for their input as well in this regard.  After all, your approach may be the best in the end, because you are not directly writing and compiling the source code.

3)     Consider the use of automation:

This one actually goes out to the IT Security team.  Software developers have better access to the most modern tools than we do, so it is imperative that you make the case to your CISO or manager that in an effort to keep up on the same pace as the software development team, you need to have some more modern technology, especially when it comes to automation.  By using the tools of AI and ML, you can more easily spot any weaknesses or gaps in the source code, and have that fixed.  Of course, the more complex ones will need human intervention from a software developer in order to repair them.  In a way, this is a sense of creating goodwill, and you are showing your software developers that you want to help them out too, and that you respect and value the time constraints that they are under as well.  But in this regard, always keep everybody informed of any remediations you have put into the source code, just so that nobody is surprised at the very end.

4)     Timing is everything:

In this regard, just don’t wait until the very end of the project to tell your software development team what you have found and what needs to be corrected.  Rather, this should start very early in the process, and should keep continuing as the development process continues.  I have always been advocate of this, as I have written about the importance of this in previous blogs.  But this is where the mindset of open, honest communications must take place, and will take a great deal of effort if it does not already exist.

My Thoughts On This:

Well, there you have it.  Some of more of my “free” suggestions.  Now I am by no means a software developer, nor would I even attempt to even become one.  But I know enough of both sides of the equation to speak something about this.  Its time that we end the siloed approach to Cybersecurity, after all it takes a village to keep one step ahead of the Cyberattacker. And this blog is just one small steppingstone in that direction.