Creative, inspiring CISOs and CIOs have the power to innovate and shape our digital world, but they can also be instrumental in transforming an organizations security culture.
A version of this article appeared on DevOps.com; it has been re-titled and updated to include new information.
While CISOs and CIOs have the unenviable position of taking the lions share of accountability for software security, especially in the event of an embarrassing company data breach, they are also afforded a unique opportunity of increasing relevance: they are the new innovators, and they can be highly influential with the right approach. Every organization on the planet, both public and commercial, is fighting to retain (and gain) their market space in a rapidly digitizing world. Customers expect a seamless online experience from both past and future products, and a "digital-first" business approach is becoming mandatory. After all, if these expectations are not met, there's almost certainly a competitor ready to swoop on the opportunity.
So, what does that mean for the modern CISO, or CIO? Naturally, it means they are employing teams of developers, each creating line after line of the code that forms their digital product or service. Cybersecurity, while a chief consideration for many years, is an increasing risk factor as more and more business operations are conducted online and in the sights of attackers. The implications of a breach are enormous, but opting out of digitization is not an option.
Creative CISOs and CIOs are in a prime position to continue forging the path of our digital futures, together with their AppSec and development teams. They will undoubtedly shape the long-term innovation of business, government and public services online, but they bear the heavy responsibility of balancing rapid speed-to-market goals, high software quality and mitigating security risk.
This balance has been, to date, immensely difficult to strike. It has led to development teams that are often fragmented, with a general primary focus on delivering features and functions, without consideration of the vulnerabilities they could be creating in the code they are so quickly churning out. AppSec specialists constantly fix the same mistakes, while the threat of a breach from a relatively simple back door being left open looms large.
If our data is to remain safe, CISOs and CIOs need to get creative with the way their teams work together, and forge a culture of positive security and shared responsibility from the top down. Just look at the catastrophic consequences faced by Marriott as a result of their 2018 breach: A GDPR fine of over USD $123 million, more than 500 million records stolen and a security reputation in tatters. This disaster occurred in major part as a direct result of insecure coding practices, with SQL injection vulnerabilities uncovered as early as 2014 on Starwoods servers, a company acquired by Marriott in 2016. Their subsequent use of the software clearly went unchecked from an application security perspective. This gave malicious attackers multiple years to access and acquire data, while other vulnerabilities, like weak passwords, left more holes to exploit over time.
CIOs and CISOs need to consider the state of their own software security climates very carefully. How security-aware is the average developer? How well are the AppSec and development teams working together? There is no "magic wand" fix, but the culture, training and support can be worked on and improved. Development teams can transform from the first line of data breach risk in the organization, to the security superheroes that stop bad code before it ever goes to production.
Where does your own dev team fit? I have created this secure coding checklist to help CIOs and CISOs identify whether their development teams are truly equipped to be secure coding champions, helping to innovate with faster, better and safer code (or, indeed, whether you're in need of security program overhaul):
In the future of software, securing the network layer using outdated security measures is simply not good enough (and, let's face it, is rarely successful anyway) even against semi-professional hackers. Among many consistent reports, Verizon's "2017 Data Breach Investigations Report" cites that a staggering 35 percent of data breaches today are caused by web application vulnerabilities.
Web application security is equally as important as network security; ignoring this and failing to budget for and instill the fundamental, basic protective layer of AppSec measures could leave you well and truly open to a breach.
The current approach to application security is quite tool-heavy, focusing on moving from right to left in the software development life cycle (SDLC). This, by definition and design, acknowledges the process is flawed and supports a detection and reaction outcome. Security teams are searching for and detecting vulnerabilities in code that is already written, reacting to fix committed code instead of ensuring it is bug-free as it crafted. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them as they are written in the IDE. This doesn't even take into account the production delays, double-handling and time spent in remedying the same well-known security issues over and over.
A truly robust security culture insists on starting left, inspiring security champions within the developer cohort, while giving the development team the right tools and training to grow and act with a secure coding mindset. There is a focus on continuous self-development, and flexing their problem-solving muscles so they can be the first line of defense in their organization, preventing common vulnerabilities from occurring in the first place.
The vast majority of security training solutions (online and CBT) focus on building knowledge instead of practical skills that directly relate to their jobs. For developers to thrive and engage in writing secure code, they need regular access to contextual, hands-on learning that actively encourages them to keep training and developing skills in a real environment. They need to learn about recently identified vulnerabilities, with real code examples, and be able to work in their preferred languages and frameworks. This learning experience is effective in helping them understand how to locate, identify and fix known vulnerabilities in the code they are actively working on in the course of their jobs.
While there are many knowledgeable teachers out there, and plenty of information on fixing security vulnerabilities, thumbing through textbooks or watching hours of video fails to engage the mind of many creative, problem-solving developers, and if the constant stream of data breaches is any indication, remains largely ineffective in preventing vulnerabilities from entering code.
A vital step in ensuring a security-first mindset is being built within a development team is to collect and review evidence. This should not be an assumption or a guessing game: developers are either security-minded, or they are not.
Metrics seek to prove to the developer and their organization that their hard work is paying off, and their individual secure coding skills are improving. You can't improve what you cannot measure. There should be relevant assessments, and these should help identify the progress of your development teams in real-time as well as benchmarking their secure coding strengths and weaknesses for continuous improvement.
Too often, security training becomes a "tick-the-box" exercise for organizations, with no emphasis on ensuring this training has been effective, engaged with or even retained.
Many organizations decide to contract out development work to third-party agencies. Whether they exist on- or offshore, their general secure coding abilities and practices are a relative mystery to their client. In the best case, the only form of assurance an organization will receive relating to security is a statement in the contract requiring the deliverable to be "secure." Very few companies take measures to verify the skills of these development houses upfront, thus running the risk of being delivered software that works as briefed, yet has been built without following sound secure coding practices. Worse yet, if the purchasing company is not aware of any inherent security flaws within the application, it risks sending vulnerable software out into the wild.
The most common scenario is that any vulnerabilities get picked up by dedicated security specialists (individuals that are difficult to source and come at a high cost) you are faced with a delay of your go-live date, and possible contractual discussions on who needs to pay for fixing these security weaknesses. However, if you're smart upfront and assess the application security skills of the developers who are going to build your next application, you save a lot of potential delays, frustration, and cash.
More than 85 percent of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities"the OWASP Top 10. At a bare minimum, your application security training must cover these, in addition to many more vulnerability types. The training challenges your developers contend with must be revised and updated on a regular basis, with new challenges for either new coding frameworks or new vulnerability types.
Precision training using real-world secure coding scenarios should be the standard; vague general knowledge is simply not effective. (Wondering what these secure coding scenarios could look like? Check out our Coders Conquer Security blog series; there's a playable challenge in each post).
Every developer-heavy organization should invest in a security champion"someone who is going to take responsibility for upholding a high security standard within the dev team. Their purpose is to be a support point of contact for anyone with questions around security, as well as become the chief advocate for following security best practices.
They are a vital piece of the security culture puzzle; a great security champion can keep the momentum going from intensive training, ensure all members of the team have what they need and continue advocating for support.
If your organization is one in which agile development is practiced, or indeed you are faced with frequent updates to company-built applications, automating parts of your security is one of the only ways to keep up with the frantic pace and volume of work.
There are tools available at each stage of the SDLC that will serve as advisers, quality gatekeepers or detection tools. In addition, some tools run automated tests over the code, simulating attempted hacking once the software is in production. All have their own set of benefits and challenges, and none can provide a catchall, 100 percent guarantee that no security threats exist within the application. The number-one preventative measure you can employ is that the earlier you can capture the weakness, the faster and cheaper it is to remediate it with the least impact on your business.
So, how did your organization fare against the above checklist?
While CISOs and CIOs are essentially forced to aggressively build their enterprise DevOps and DecSecOps capabilities, that doesnt mean there is no time to consider and implement the right tools and training across teams. Secure coding skills will be a weapon"not a hindrance to"innovation, and foregoing them could spell the absolute destruction of company reputation and data. These skills represent critical capabilities and a much cheaper long-term solution to reducing vulnerabilities and mitigating risk.
A brilliant, innovative CISO has the power to orchestrate a healthy security culture from the top down; ensure your staff has what they need to execute security best practices effectively.
Pieter Danhieux is a security expert and the co-founder of Secure Code Warrior.