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.
No comments:
Post a Comment