New Year Resolution: Software Development Application Security Strategic Prioritization, SSDF Top 10

Implementing security and regulatory compliance SSDF practices into an efficient Software Development Life Cycle (SSDL) can be quite daunting due to the scope of practices and tooling required. Just as "Rome wasn't built in a day," security implementation and improvement plans need to be prioritized based on highest business risk, and most cost-effective "bang for the buck" improvement investments. 

While it might be tempting to try addressing all of the below at once, or even cherry pick through the list, they each have success dependencies on each other that are need to acheive effective execution: Document, Assess, Improve, Adjust, Repeat.

1. "Be Prepared" for today's advanced ransomware attack threats

"Being prepared" is about everyone knowing who is responsible for security risk and incident responses, identifying the actions required by each responsible stakeholder, setting realistic and appropriate response timelines needed to support business product and service objectives, and knowing the total scope of assets that could be attacked.

1. Responsibility Assignment Matrix (RASIC)
   Defining 'who' is responsible for doing 'what':
1. Information Security can be guided by an organization's Governance, Risk, and Compliance (GRC) functional departments, but requires implementation and practice by IT Operations and Software Product Owners to be effective.
2. All involved stakeholders responsible for assessing, responding, and resolving software product risks and incidents which includes, but isn't limited, to Legal and Marcomms regulatory compliance disclosure responses.
3. The RASIC should be maintained in a easily accessible online documentation repository that is updated immediately whenever there are personnel or org changes.
2. Security Incident Response Playbooks
   For each Business Continuity & Disaster Recovery function in the RASIC, ensure that there are published and up-to-date playbooks for all:
1. Security Incident RASIC stakeholders
2. All application product development teams
3. All platform product owning teams
4. Sensitive data stores and processors administrative owners
3. SLOs (Service Level Objectives)
   Defined for risks and incident response
   Advised and facilitated by Information Security, it is the organization's Executive Management Board who is responsible for establishing the business performance objectives and delivery funding, with operational considerations input from affected product owners.
4. Know your Attack Surface & Catalog Your Assets
   In order to adequately define defenses and responses, organizations need to have always-current catalog of their sanctioned:
1. Software product applications (web, mobile, APIs) components
2. Data repositories
3. Applications and data hosting Platforms & Environments (Infrastructure and network segmentations)
4. CI/CD Pipelines
5. Source code and compiled versions binary repositories
5. Automate Risk Alerting and Reporting
1. Alert Product Owners immediately for any newly detected production risks
2. Provide management chain real-time risk status dashboards and weekly reports
3. Deactivate and Decommission any unused assets to reduce potential attack exploitation.
4. Platform Security Patching (VMs, Containers)

2. Protect Against External Threats

1. Monitoring Your Publicly Known Attack Exploit Weakness Vulnerability Risks
   Daily monitoring of public web vulnerability search engines (e.g. Shodan) and security posture reporting services (i.e. SecurityScoreCard, et al)
2. SCA Testing: Monitoring Your Vulnerability to Software Supply Chain Poisoning Risks
1. Use Software Compositional Analysis (SCA) scanners configured to update daily with latest vulnerability detection signatures.
2. Establish and require that all developed software is only able to use 3rd party components that are managed by organizationally controlled Software Binary Repository Managers.
3. Ensure SCA scans are run on all applicable existing binaries whenever there are new vulnerability detection updates (e.g. daily), and whenever new binaries are added.
3. DAST Testing: Detecting publicly known application attack weaknesses
1. Dynamic Application Security Testing (DAST) provides automated adversarial testing that should in run in all environments (Production, Test, and Development) to identify risks.
2. i. DAST scans should be configured to check for detection updates daily, and then run on applications whenever there are applicable detection updates or when a new build is deployed.
4. Penetration Testing: Expert manual adversarial risk testing
1. Expert manual penetration testing is able to test beyond the capabilities of DAST.
2. Ideally these should be conducted every planning increment to accommodate new attack scenario methods, and whenever new product major functionality is being QA'ed for production release.

3. Protect Against Inside Threats

"Inside Threats" is not just about malicious employees, but can be any external attacker with trusted network access or naively careless employees.

1. DevSecOps: to protect against internal supply chain poisoning
1. Security Hardening of all organizationally used CI/CD Pipelines
2. IAM (Identify and Access Management)
3. Limiting actions and permissions to trusted individuals
4. "Separation of Duties" controls to protect against potential rogue abuse
5. Implementation of organizational release QA SSDLC compliance requirements
   (e.g. ensuring SSDLC vulnerability scans and assessments completed with vulnerability risks within organizational risk acceptance standards)
2. SSDLC Design Threat Assessment
1. Security begins with Design. Vulnerability testing tools can only detect commonly exploited weaknesses, but have no way of determining unintended misuse or all types of sensitive data disclosure (e.g. microservice architecture solutions with open promiscuous APIs).
2. Technical Design Threat Assessments should be conducted by trained security experts whenever there are solution functional design changes.
3. SSDLC Security Code Reviews
1. The objective is to prevent production releases with preventable vulnerabilities.
2. These reviews should be performed by trained security experts as part of final QA for solution functional change production releases; leveraging SCA, DAST, SAST scans and Solution Design documentation.

4. Protect Sensitive Data from Unauthorized Exfiltration Exposure

To provide protection against large datasets simply being copied and transferred outside the organization's control, sensitive data needs to be strongly encrypted not only during processing communications (e.g. "in transit", TLS), but also wherever it is stored ("at rest"). While the encrypted data files could be transferred externally, the information would be scrambled to the point of not being of any use or value.

The implementation of strong encryption also necessitates that implementation of robust cryptographic keys and certificates management. With the anticipated arrival of commercial quantum computing in the coming years, organizations should also begin planning to upgrade existing solutions to implement new secure post-quantum encryption algorithms.

5. Actively Monitor and Manage Vulnerability Risks & SSDF Performance (maturity)

"You can't manage what you can measure"
Organizational Security Risk & Performance online published dashboards are needed to develop security awareness and instill daily security quality improvement culture.

1. Dashboards and summary reporting for status and trend performance evaluation
1. Vulnerability Risks - for both known (fully scanned/tested) and unknown (incomplete monitoring): Unknown vs Unmanaged %
2. SSDLC Compliance (practice confidence)
3. Prod Vulnerability Remediation Performance
2. Dashboards need to be
1. Visible to everyone in the organization responsible for security
   When performance status information hidden, then security becomes "Out of sight, Out of mind".
   Prime audience: Software and system developers, business product owners,
2. Realtime - automated & updated at least daily
3. Regularly reviewed as part of Management Reviews weekly & monthly
4. Used for Strategic Planning Prioritization for product release delivery incremental planning.

6. Ransomware Attack Response Readiness Drills

To truly assess organization readiness for security attacks, regularly conduct mock drills for a random selection of applications. Measure ability to:

1. Quickly reset of all potentially comprised user and service account credentials
2. Deploy security fix patches (with full integration, regression, and AppSec testing validations).
3. Identify sensitive data to could have been exposed if strong encryption not validated as being present.
4. Mock management chain notifications and escalations for applicable disclosure requirements.

7. Promote and Strengthen Product Security Excellence Culture

"If you build it they will come" - NOT!
It would be convenient to think that InfoSec departments can single-handedly address and mitigate security threats. The reality is that security is a team sport that requires full prioritization and engagement throughout the organization, from top-down, with everyone understanding their role and responsibilities.

1. Awareness and Education Training
1. Needs to be provided and required for:
1. All developers, managers, directors, digital product managers, project managers, and executives - Top Threats and Defenses of SSDF/SSDLC
2. Developers - security design and coding best practices
3. Executive Board - Attack Chain Threats, SSDF defenses, and organizational RASIC responsibilities.
2. Training curriculum to cover
1. Business Risk Threats - Software Attack Chain: OSC&R/Mitre
1. Threat Actors types (external and internal)
   
2. Including attacks against AI applications
2. Organizational SSDLC requirements and tools 
3. Coding Weakness prevention for organizational technology formulary
2. Provide Incentives & Consequences
1. Celebrate Gold Star Security Champion Product Teams - those who fully follow the organization's SSDLC standards and remediation vulnerabilities faster than SLOs
2. Penalize Non-Conforming application product teams and managers (e.g. bonus eligibility criteria) who release production products with incomplete SSDLC testing and known/preventable vulnerabilities.

8. Regularly Assess Organizational Readiness and Maturity

Senior leadership and stakeholders planning increment reviews of organizational security objectives to actual performance metrics from:

• Publicly Known Security Risk Reports
• Penetration Testing
• Security Design Assessments
• Security Code Reviews
• Platform Patching
• Ransomware Attack Simulation Drills

9. Don't overlook AI Security

Incorporation of Large Language Models (LLMs) and Machine Learning (ML) into applications is nothing new or different than using any other type of 3rd party component; however there are additional attack opportunities and sensitive data tampering considerations that must be considered to defend applications and provide operational continuity resiliency.

10. Continuous Improvement

For each organization Planning Increment reviews, 

1.  Review outcomes performance vs investments
1. For Cost Reductions identify automation opportunities
2. Review resource allocations and prioritizations
   
1. Address "unknowns" and incomplete coverage
3. Ensure continuous monitoring, analytics, and management compliance performance reporting

Conclusion

In an ideal world, quality & security is prioritized throughout the organization from the top down. But that reality is that most organizations choose to prioritize speed and cost of product development over quality
(e.g. the Project Management Triangle: "“You can have it good, fast, or cheap. Pick two.”). 

Pragmatically documenting realistic security performance maturity,
developing detailed improvement plans,
prioritized based on risk reduction,
with continuous status reporting,
is the way to move forward to mitigating potential attack business and operational impacts.