Last month, Equifax announced that management was aware of the security vulnerability responsible for the massive breach, and even knew there was an available patching solution. Yet, no one took action for two months. Leading me to the question: how much does work culture affect IT strategy and what changes can be made to strengthen cybersecurity?
In my previous post, I discussed the nature of open source software and security vulnerabilities. Well-maintained open source software is critical to allowing faster, more robust software development. But, its shared nature increases vulnerability footprint that affect companies using it. Fortunately, open source projects take security seriously and aggressively patch any exploits. This rapid response to security makes software safer, but is only half the battle. The other half is how teams and companies deal with patching and awareness of exploits.
Companies of all sizes and industries vary in software development approach. Company culture and attitudes towards security will determine the quality of software and applications produced. A quality and security focused development culture will help drive good process that protects against common security vulnerabilities and will make product development more predictable and enjoyable.
So, how do you know if your organizational culture is affecting software and cybersecurity? Let’s look at some key indicators of an unhealthy development culture that will directly affect security.
1. You treat security as a step
When teams treat security as a step, it usually falls last in the software development process. It is very common for software to be reviewed by an external team that “certifies” that the software is secure. This late, last-minute approach is decoupled from development and recruitment processes that drive application builds. Treating security as a last step housekeeping effort sets teams up to look at security as a hurdle to overcome rather than something that must be built into the application being developed. External reviews can create an adversarial relationship where the team feels it is just trying to get software in production and the reviewer feels the team is dodging security to get it released.
A better approach is to think about security during all phases of software development. This should start with the requirements. Externally facing components, data access and common vulnerabilities should get scrutinized to ensure the team is aware of common security threats during development. In addition, all developers, system administrators and testers should read the Open Web Application Security Project (OWASP), and have a passing understanding of what causes security issues.
2. You’re not actively automating
Too many teams build and deploy software by hand. Manual software development as a primary form of production is indicative of a hazardous “just get it done” organizational culture. It can be because the team is filled with cowboys or heroes that will dive in to fix problems by hand rather than work to improve the automation. Manual intervention becomes a problem because it reduces the number of times software will be touched and reviewed. There are two different reasons for this:
The number of hours a team can dedicate to anything is fixed. More tasks equate to less time available.
Verifying quality and security is labor intensive and time consuming. Human nature dictates that these tasks are often avoided and delayed as they require interrupting other important items.
The solution is to instill an “automate everything” mindset within technology teams. While it is impossible to automate all repeating tasks, an automation-focused team will attempt to automate as much as possible. This effort pays off by not only further automation, but also frees time for tasks that can’t be automated.
If the team does not have an automation culture, it is best to start with small automation projects, such as, the last step of deployment or regular builds of the application. Small automation projects like these can be thought of as frameworks that can expanded with every new piece of automation.
3. Your team lacks confidence in tests
A lack of confidence in quality is usually driven by manual testing or low levels of automated testing. And, teams that don’t have confidence in the applications they produce will be hesitant to make any change. These changes changes include patches for critical security vulnerabilities.
When most of an application is not covered by tests, the team does not know what will break or how. Companies with this sort of software will sit on builds with known fixes for longer periods of time manually testing in order to avoid introducing new defects and to allow for features to accumulate for the infrequent releases. This accumulation is the result of everyone wanting to get in on the releases when they happen. Unfortunately with regards to security, unpatched vulnerabilities are in fact critical items falling through the crack.
Confidence in the quality of the software allows frequent updates. Frequent updates ensure that patched vulnerabilities are addressed in a timely fashion. Teams should be focused on maintaining tests to cover enough of the application to ensure they have the confidence to deploy. This is an item of culture. It is about focusing on quality in every build and with every line of code added to an application. It can be thought of as a subset of the automate everything culture focused on testing and quality. Teams can approach introducing it in the same way as other automation, by starting with a seed and expanding it until they have something that works well enough for them.
4. Your organization is built into silos
Some, organizations encourage team members to focus on their area of expertise: development, QA, operations, etc. This is especially true with heavily matrixed organizations where each of the team member building an application is managed with similar specialists. It is common for companies to align IT under a development manager, a quality manager, a PMO manager, and an IT manager operations. These units can even come from other business units. This structure encourages members of a team to feel that they are only on loan to a project and need to think about their specialty above the needs of the project. Team members don’t get promoted for cross-discipline work such as security.
While I do recommend an organizational structure that aligns teams with the project holistically, I understand that this can be a massive change to some organizations and may even be unachievable. If that is the case, I encourage team members to view the project as a whole and not through their own lenses. This means asking questions about cross cutting items such as performance, quality, and security whenever they work on something for the project. Project managers can encourage this behavior by adding security time to planning and leads can encourage it in the code review process with checklists.
The culture of software development directly affects the quality and security of applications that teams build. Focusing on security as a part of the entire software process helps drive the idea that security is important to every member of the team. Developing a culture of automation helps eliminate time consuming repetitive tasks and busy-work. While, a culture of quality automation helps drive a confidence in the application that allows teams to release frequently. All of these items together help companies stay on top of changing security vulnerabilities and reduce the chance of a major breach caused by software they create.