3 common mistakes companies make when starting a software security initiative
Organizations typically make three common mistakes when establishing a software security initiative (SSI). The ability to reflect on these mistakes can help firms determine whether or not their program is moving in the right direction. Let’s explore some of the most common software security initiative mistakes and alternate approaches to get firms on the right track.
Ad-hoc program vs. roadmap-based program
Until recently, most firms didn’t perceive a SSI as a separate program. The software security functions were either ignored or haphazardly accomplished by leveraging other divisions in the organization such as development, IT operations, and network teams.
Such ad-hoc strategies allow firms to cut corners to meet short-term needs instead of developing a long-term strategy. Ad-hoc programs address only tactical problems, and are often achieved by conducting third-party security assessments or utilizing security-as-a-service (SaaS). Most importantly, ad-hoc programs lack consistency while integrating security among development groups.
The right track
A roadmap-based program, on the other hand, allows firms to build a more sustainable SSI. It allows organizations to build a quarterly plan and to pursue incremental progress in the appropriate software security domains and practices. As an example, a mature organization interested in setting up an automated scanning factory for static code analysis will ensure appropriate planning and a pilot is completed before integrating scans with build environments.
A dedicated program also provides governance to ensure discipline across a large development organization. Executives looking for meaningful security metrics to demonstrate success (ROI) must develop a roadmap-based SSI.
Assessment-centric vs. capability-centric
Another common mistake is that organizations overly rely on an assessment-centric approach to security—performing miscellaneous security assessments on their application portfolio. Commonly applied assessments include secure code review, application penetration testing, network assessments, architecture risk analysis, and fuzzing.
The right track
Although security assessments are valuable in discovering defects surfacing in applications, they can provide even more value if relevant activities are grouped together and executed as “capabilities.” An example is the “defect discovery—source code review” capability which includes the following security activities performed by a software security group (SSG):
- Ad-hoc reviews
- Manual code review along with automated tools
- Automated tools with tailored code review rules
- Builds a factory
- Automates malicious code detection
A capability-centric approach will enable the SSG owner to group similar activities together and focus on not only discovering issues, but also working to resolve current issues, and preventing future issues from developing.
Thus, as the security program within a firm matures, it should adopt a capability-centric view. Some of the other common security capabilities include:
- Defect discovery
- Open source management
- Metrics
- Satellite
- Vendor management
- Risk and compliance
- Attack intelligence.
A capability-centric approach also enable organizations to identify appropriate secure software development life cycle (SSDLC) gates, enforce security policies and standards, adopt secure by design principles, and track metrics to determine what’s working and what needs improvement.
Compliance-driven vs. risk-based
The third and most commonly observed mistake is over-reliance on compliance requirements. Adhering to “checkbox compliance” does not necessarily make a piece of software more secure. Rather, it simply indicates that minimum requirements were met. For example, many major hacks of 2015 happened in firms that were complaint with known standards and benchmarks.
In one recent example, the FTC took legal action against Wyndham for failing to provide security measures to consumers. Wyndham was hacked three times but didn’t take appropriate measures to secure their customers’ information. TJ Maxx, Wyndham Worldwide, and Heartland Payment Systems were PCI compliant, but they were all breached. This indicates that fulfilling a self-assessments questionnaire (SAQ) doesn’t make an organization any more secure, and thus compliance requirements can’t be used as a measuring stick for a firm’s application or software security. Often times, these standards are high-level and provide justification to business users to file for an exception or risk acceptance.
The right track
It is essential that organizations develop a risk-based view to ensure loopholes are closed by integrating security policies with remediation processes. A qualified and independent third-party can help conduct a comprehensive risk assessment, ensure the effectiveness of all the required security controls, and provide details on a firms risk exposure.
It is noteworthy to state that the settlement with the FTC requires Wyndham to “establish, implement, and maintain a comprehensive information security program that is reasonably designed to protect the security, confidentiality, and integrity of cardholder data” for the next 20 years.
Gaining clarity
Firms often try to cut corners by conducting security assessments and only following minimum checkbox compliance requirements. Such ad-hoc approaches simply prolong the problem and doesn’t fix the root cause. A roadmap-based program can help organizations build various capabilities and core software security competencies while addressing appropriate business risks. Establishing a SSI is an ongoing effort and requires firms to develop a long-term and empirical strategy. A proactive strategy allows firms to stay ahead of the bad guys.
