The Problem
Let’s face it, we have a problem. Hackers are breaching organizations’ software infrastructure and applications daily. Most of these breaches are preventable, but yet they still happen in ever-growing numbers. From my experience, I don’t believe that we are investing enough in the skills of the developers who are building our software as well as the engineers who create the deployment environments. Security needs to be baked in at all levels and this includes investment in the training of an organization’s software development staff.
I believe that there are widespread assumptions about the security education of software developers who have come out of four-year programs. These off-the-mark assumptions are driving the investment in the training of an organization’s development staff. Would you be surprised to know that “More than 76% of college-educated respondents said they weren’t required to complete any courses focused on security during their higher education study.”1? Most developers (64%) learn their security skills on the job and that “a miniscule 4% said they learned their most relevant skills from third-party training.”1? “Only about half of respondents said their employers paid for any additional training since they entered the workforce.”1 Clearly, we can not assume that most software developers understand security risks in the code that they are developing.
I was surprised by these findings because as someone who was in college in the late 70’s through early 80’s, security wasn’t a big deal because most computers weren’t connected to a publicly accessible network. As the internet became available, usage expanded, and attacks became more common, I assumed that higher education would keep pace. However, it turns out that the curriculum guidelines created by the Association of Computer Machinery (ACM) recommend that someone pursuing a software engineering degree receive four to eight lecture hours of security-based training, that’s not per semester, but for their entire bachelor’s degree program. I’m stunned at this because I currently spend at least that much each month in professional study. I would not be surprised if executives who set the priorities for software development organizations are making the same false assumptions as I did.
In order to develop and deploy systems that follow a “Defense in Depth” strategy of embedding security into every level of an application, as well as its deployment environment(s), the managers, software developers, DevOps engineers, and operations engineers must have the necessary security skills.
How do we go about correcting this problem? I believe that we must begin by doing the following:
- Convince leadership that security must be baked into our software products, processes, and infrastructure; that not doing so may leave the company exposed to terminal risks (e.g. witness calls for the revocation of Equifax’s corporate charter). The priorities and budget for security must come from the top.
- Equip our software developers, DevOps, and operations engineers with the knowledge to do their jobs securely and efficiently and renew that training regularly because threats change constantly.
- Equip our software development managers with an understanding of how application security is baked into secure applications and the controls that can be implemented to do so.
We need to recognize that our development team’s security skills may not be at the level we think it is. Addressing problems with a “Defense in Depth” approach requires talented and knowledgeable staff. The first step in solving a problem is recognizing that we have one.
References
- The DevSecOps Global Skills Survey: https://info.veracode.com/analyst-report-devsecops-global-skill-survey.html
*American Cyber Security Management (AmericanCSM.com) is focused on reducing your risk of data misuse. We do this through our Security, Privacy and DevOps offerings, delivered by seasoned experts. We can ensure your Agile delivery processes are secured and efficient, while maximizing your investments.
I’ve been spending a lot of time lately with early startups and small business owners talking about privacy and security. My previous jobs sent me into some very large enterprises to solve for some very large privacy and security concerns. One has to ask, are these two worlds so different? I’d have to say yes and no. A recent series of outages involving an industry-specific ERP vendor understandably had business leaders in the marketplace upset. Many days worth of revenue was lost and regulatory reporting was halted which, in turn, froze commerce in its tracks. In fact, there is a certain amount of outrage amongst the customers experiencing the outages; there’s also a certain amount of learned helplessness. This got me to thinking: how can we apply a little Fortune 500 wisdom to help out the folks just getting started?
Where is the best website for breach data history? This has been a common question and one that everyone seems to have a personal answer to. In the spirit of Cyber Security Awareness Month, here are some good resources to consider.
The world seems to be a buzz about GDPR. If you’re not buzzing – you’re not in the know. People want to know what it is, who has to deal with it, when do they have to take action, and where they can turn to for help. Simply put, GDPR is the European Union’s (EU) latest attempt to ensure that it can control the data protection for all individuals within the EU. GDPR stands for the General Data Protection Regulation 2016/679 and was adopted by the European Parliament on April 14, 2016, which goes into enforcement on May 25, 2018. It is the most important privacy change in the last 20 years. If you offer goods and services in Europe, have European employees, partners, or suppliers, you’ll need to comply with some form of GDPR.