Building Data Protection into Product Development
By Scott Martin
The cost of bugs
In the last year alone, 31 U.S. states enacted new cybersecurity legislation, continuing a trend that will only rise as governments worldwide respond to growing public concern about data protection. These new regulations add to the already complex requirements that organizations struggle to meet. They also pile onto the high costs that companies face after data breaches in the form of lost revenue, data recovery expenses, litigation, fines, and reputational damage.
Few application architects, software developers, or systems teams understand these regulations and the impact that non-compliance can have on the companies for which they work. All too often, these teams conduct security certifications and approvals right before they release the code for a new application into production rather than in the early stages of development. By that time, the cost of fixing software bugs that create security vulnerabilities can be up to 30 times higher, according to the National Institute of Standards and Technology.
By building data protection protocols into the five phases of application development, businesses can more easily comply with the growing body of legislation and reduce their remediation costs. The best way to do this is to define the regulations that apply to your business, product, or solution as nonfunctional requirements (NFRs) within the software development and deployment processes. Coupling these NFRs with software development “rhythms” will help ensure that developers and systems teams perform regular security checks such as code scanning, system scanning and penetration testing that enable them to detect and resolve vulnerabilities before hackers can exploit them.
The vulnerabilities at stake
Taking an “early and often” approach to testing for data security issues will enable application architects and systems teams to detect the following types of vulnerabilities, among others, before it’s too late:
SQL injection – Hackers insert malicious SQL statements into input fields to breach databases. This vulnerability, which accounts for 8% of cyber-attacks, can be prevented by good coding practices and code scanning tools that alert developers to weaknesses in their code.
Unpatched software – Installing software updates and patches as soon as they are released is critical to limiting vulnerabilities. The Equifax data breach is just one example of how failing to apply a simple patch left its system open to attack.
Unverified configurations – Failure to test or validate the deployed configuration to ensure it is secure. For example, a client discovered that a critical production database was not encrypted. Fixing this problem required scheduling a maintenance window, completing an impact analysis, and conducting regression testing – a process that took three months. If the team had performed this test during the development process, it could have resolved the issue in 15 minutes.
How information security rhythms help
Companies can reduce their vulnerability to data breaches by defining the regulations as NFRs and establishing information security rhythms to verify those NFRs are met. These security rhythms are a series of testing, diagnostic, and remedial steps developers, systems teams, and security professionals should take throughout the design, development, deployment, and operations cycles of a solution.
Taking this approach to data protection reduces detection and remediation costs because developers can address problems as part of the standard development process rather than as an exception that takes more time and effort to fix. For example, some static testing and remediation can be done in minutes as developers are writing code, whereas conducting the same code analysis just before a release would take eight hours or more. That’s because a lead developer would need to review the report and allocate the work to another developer who will locate the issue, analyze the code, implement a fix, and hopefully not break the code.
Also, if a non-development team finds a critical vulnerability, it might require a patch release, which means more development time and an out-of-sequence release that could take upwards of 200 hours depending on the complexity of the release process.
Establishing a rhythm
Teams should perform security rhythms at regular intervals during the development and deployment of software solutions. As the diagram below illustrates, different kinds of tests should be performed on a daily, weekly, monthly, or annual basis.
1. Daily rhythms
Every day developers should conduct a series of static code analyses to find and fix weaknesses in their code before they check it in and include their completion of these activities in the Dev Ops pipeline. These tests include a robustness analysis that finds software execution issues, poorly written code, overly complicated code, code duplication, etc. Addressing these issues early not only helps reduce the number of bugs found during testing but removes confusion about what the code is supposed to do. That way, other developers are less likely to inadvertently introduce new bugs.Developers should also run daily vulnerability analysis tools to find insecure coding patterns such as SQL injection, hard-coded passwords, poorly managed error handling, and other suspect programming practices. Each team will need to determine what steps must be completed before code can be checked-in or included in a system build. Some teams may require their members to clear all findings before moving the code into integration. The goal is to have clean code every day.
2. Weekly rhythms
Some tests take too long to run daily and should be conducted weekly instead, such as static testing that analyzes source code for vulnerabilities like buffer overflows. These tools provide reporting metrics for each codebase that should be monitored by software quality assurance, software management, and other teams to ensure they comply with company standards.Some of these solutions offer an Integrated Development Environment (IDE) that can be incorporated into the daily workflow to provide an independent layer of vulnerability testing and reporting and help measure compliance. By making these code checks part of the developers’ weekly processes, they can fix issues while the code is still fresh in their minds, not only speeding the fix but training the developer on how to prevent future defects.
3. Monthly rhythms
Every six to twelve weeks, the systems team should use vulnerability tools that look for known weaknesses in systems as well as automated penetration tests that exploit these weaknesses to determine how much access an attacker could gain. These tools help identify misconfigurations, a lack of required patches, and zero-day threats. They also scan for common software vulnerabilities, which provides an additional check on whether teams are effectively executing the daily and weekly security rhythms. By coupling regular automated penetration and vulnerability scanning with monthly patching cycles, teams can mitigate the side effects of patching before they affect the business. This monthly check should also include manual penetration testing, which takes more time and effort than automated penetration tests but can uncover vulnerabilities that only a human can find. If teams have properly executed the previous layers of testing, this process will yield little-to-no findings. However, it provides an excellent cross-check to catch vulnerabilities that may have been missed.
4. Annual rhythms
Companies should also conduct a yearly review of their applications and infrastructure on which they run to identify security holes created by things like the installation of new hardware and software, software upgrades, and unpatched systems. Along with penetration testing, this review can help find hidden vulnerabilities that creep into your systems over time.
Getting started
To establish security rhythms, first identify which security rules and regulations apply to your organization. Then consult with technical, security, and business stakeholders to determine the appropriate NFRs for meeting these requirements. Next, determine the tools and processes everyone will use for activities such as logging bugs, remediating issues, and deciding when code is safe to release. Define the types of scanning you will perform, including where and how it is done.
Finally, set objective measures and thresholds for these rhythms, assign a group to monitor and assure compliance with the NFRs, the rhythms, and any associated policies. Use these findings to give process changes to the teams, starting with the most-compliance critical issues first.
Ready, set, go
As the risk of cyberattacks continues to rise, companies will need more ways to protect themselves from data breaches that can damage their reputation and devastate their businesses. As governments continue to pass new data regulations, companies must find better ways to comply. By building a rhythm of routine checks into their software development process, organizations can save valuable time, reduce rework, and save money. The first step is realizing that sometimes it’s better to clean-as-you-go rather than save it all to the end.