1(630)802-8605 Ravi.das@bn-inc.net

In today’s Cyber secrity world, there is often the vision that hacks are possible because of misconfigured servers and workstations, software patches and firmware upgrades have not been installed, passwords are not strong enough, employees still fall victim to Phishing and Social Engineering Attacks, etc.

While this is all true and still remains at one of the main cruxes why Cyber-attacks still do happen today, there is still another reason why they happen:  poorly written source code by software developers.

Granted, writing source code can be a very difficult proposition, there is even no way that I could become a software developer (I admit, I tried and failed on numerous occasions), and they are always under enormous pressure by tight deadlines, and often have to deal with unreasonable expectations when it comes time to launch the application.

But, Security is still one thing that is often left behind as a least priority by the software developer(s).  There are numerous reasons for this, because often they take pride in their work, and feel it is good enough.  This is of course a good thing, but it is like writing.

I may think that the way I write is good enough, but to somebody else, it may not be.  Thus, the need for the proofreading and editing cycles.

Because of that software developers feel that there is no need to Security check their source code. Another reason is that as stated before, the time pressure.  Very often, software developers leave backdoors still open, many times unintentionally.

And when the application goes to launch, they still exist, the Cyber attacker can pick up on them, and from there, depending on the application that was created, they can launch SQL Injection Attacks or even Cross Site Scripting Attacks.

Another reason why Security is an often-ignored aspect of source code development:  Confrontations between the software development team and the IT Security Staff whose job is to ensure the application is safe and secure to launch.

On October 3rd, Tanya Janca, who is a lead developer of the OWASP DevSlop project and a senior cloud advocate at Microsoft, offered her own perspectives when she spoke at the SecTor Conference, in Toronto, Canada.

She basically stated that the lack of coordination and integration between the IT Security Staff and the software development teams created a feeling insecure amongst the latter. For example, when a software developer (or really any employee) feels insecure, it very often results in reduced job involvement and poorer results.

In other words, there is a steep disconnect between the software developers and the IT Security Staff whom would often tell them to write lines of source code in a particular way with very little explanations, with no involvement what so ever.

So, in response to all this, Janca has offered a two-step plan to help remediate all of this:

  • Provide the support for the software development and IT Security teams with the processes, training and resources that they need so they can source code written and the application launched in a secure manner.
  • Initiate and maintain this new shift of mentality, or “culture change”.

It should be noted that in the source testing (especially that for Security) comes at the very end of the supply chain, which can be viewed as the following:

RequirementsàDesignàCodeàTestingàRelease

This is often viewed as a “Shift Right” approach, so Janca has advocated that the testing phase should be more to the left, at the beginning of the software development lifecycle.  In other words, a “Shift Left” mentality needs to be adopted at a macro level, in the business or corporation.  It is far easier change source code as vulnerabilities are found early on, rather than waiting till the very end.

She also said that when upper management receives the requirements for the application from the client, they should also make sure that they also have a Security checking component as well, in order to ensure that the mindset for writing secure source code is instilled early on in the process.

She also highly recommended that instead of Security checking the source at the very end, and making it a huge “exercise”, this process should be broken down into smaller steps at the very beginning stages.  This should be done through out the entire Project Management Lifecycle of the software application that is to be created.

Also, instead of having the IT Security Staff simply scan the source code for vulnerabilities and sending the results off to the software development to interpret, she recommends that they validate and confirm the scan results first, in an effort to identify any potential false positives, before the results are sent off to the software development team.

Janca also made the fact known that software developers are also employees as well, and thus they should also have access to the same level and caliber of Security Training that the other employees get as well.

To this regard, she also recommended that the upper management of an organization provide the Security tools that a software developer would need to so that they can write secure source right from the very beginning.

An example of a free Security tool set is that of the Open Web Application Security Project (OWASP).  She also stated that in an entity, there will probably be many software developers that versus the IT Security staff.

While training a software development team may take some financial resources, she said that in the end, “A Security breach will cost more than doing secure development.”  (SOURCE:  http://www.eweek.com/security/how-to-enable-developers-to-build-secure-software).

My thoughts on this?

I agree with Janca on all of these points.  As one of my podcasting guests said, no one individual or company can fight Cyber security alone . . . it literally takes a village.