0

How to make information security risks meaningful

Inclusion of application security as one of the non-negotiable factors in Software Development Life Cycle (SDLC) is often considered daunting. Reasons such as (1) SDLC team or their managers and leaders lack active engagement with DevSecOps SME’s, (2) Security experts are forced to certify SDLC code at nth hour of release due to pressure from business leaders and urgency from SDLC managers (3) SDLC team forcing DevSecOps to accept critical security risks by showing helplessness of vendor code is third party proprietary ownership and is nonnegotiable. Etc.

CISO and DevSecOps tackle these challenges with empathy as they believe often Security experts are unable to justify true technical and business information security risks to SDLC teams and wider business stakeholders. The feedback loop is missing with rational action plan, solution options to mitigate data, code vulnerability and other security risks. DevSecOps advocate that SDLC teams intend to develop secure code and solutions however lack of security SME/Expert engagement from early stages of project scope, design and development for sharing best practices and vulnerabilities risk metrics.

Often Security experts share ‘generic’ checklists drafted to comply with enterprise information security policy framework with SDLC team instead sharing specific technical solution, design pattern and coding related checklist to ensure SDLC team reduce information security risks. Moreover, security experts are not up-to-date and aware of latest unresolved vulnerabilities, solution patches and vulnerabilities detection techniques henceforth SDLC code vulnerabilities scanning is often executed with out-of-date vulnerabilities datasets or solutions. Lack of justifying business value and out of date vulnerabilities information dilute security expert’s stature in the eyes of SDLC team impacting information security importance establishment and reinforcement.

Suggested indicative tips and rational practices may trigger driving risk discussions based on data and business context between SDLC team and security experts:

Convert data to your guiding force: CISO and DevSecOps may build their case by finding the right metrics to tell their story. Data must be your guiding force, it must be part of your analysis, appropriate level of insight for interpretation and must become part of your influencing strategy. Data should become your common language of discussion from SDLC team level to executive board. It must become your default common denominator to establish trust in your findings as technical and business stakeholders trust your numbers and metric more than just believing in you.

End customer-centric metrics: While presenting SDLC teams sharing number of vulnerabilities in application makes sense however sharing same metrics to business stakeholder is pointless. Sharing business stakeholder’s metrics with executive board will not impress them. It does not mean that they don’t care however as they don’t understand its importance and meaning your (CISO and DevSecOps) efforts will be in vain.

CISO, DevSecOps or security team leaders must partner with business and technology leadership teams, SDLC managers and start cross-referencing the vulnerability statistics against the business criticality of affected applications and impacts to give the numbers a meaningful context. Next step is to simplify scoring to present the state of security in most critical applications of organization. CISO must focus on developing simplified metrics to show bottom line impact of security risks on section of operations metrics, balance sheet, behavioral index, market reputation and strategic position with peer competitors.

Develop consistent risk scoring

By contextualization and simplification of security metrics. DevSecOps team may develop Service or Product Intelligence score, to wrap data from its vulnerability databases, Governance, risk management, and compliance tooling (GRC tooling), Incident services ticketing systems, application management systems, dynamic scanning information, database and application penetration tests, IoT devices audits, etc. by weighing the from enterprise information systems against business criticality of the application being scored, and factoring types of security services used by the development team and uplifted capabilities of security champion, in its ranks. Factoring similar parameters into a single score with range of 200 to 800 to score security level.

Using single score helps to makes measurement easy for product across enterprise and track progress made over time for each application. The critical success factor for simplified score is to engage enterprise business and technology all stakeholders and ensure transparency about developing risk score and assigning risk scores. SDLC team member to marketing team will trust the score if they understand how specific score was calculated and derived besides it anyone in organization may be able to derive on score if they could assess associated security risk and parameters for any SDLC applications.

User friendly simple dashboard

DevSecOps team can build stronger trust with business and technology stakeholders if they can map dynamic risk score traceable to measurement parameters and presented on self-service dashboard. Besides it dashboard should offer any SDLC team to compare their application risk score benchmark with other application scores, recommended action plan to improve application risk scores.


Creating Simplified Dashboards

DevSecOps team can start with minimum viable risk score feature on dashboard and improve dashboard populating it with more features keeping simplicity. The primary focus of dashboard is to ensure how each application team remain focused on improving application security based on risk score and recommended solution practices instead of adding more graphics and animation bells and whistles on dashboard. Success of every dashboard will be evident executive committee members to SDLC team can self-service use, analyse, benchmark their application and reduce risk scoring.

The day when corporate executives or SDLC team can easily discuss risk score and work together as united force to improve enterprise applications will become proof of security driving organization culture and transforming it organically. 

Enterprise transformation and enterprise agility is not just about scaled agile or spotify or design thinking; it is also about building stronger business and technology team confidence with security, simplicity and psychological safety.

Share

danic

Engineer by training; Business value advocate by choice. User, Coach, Trainer and active promoter of Business Model Innovation and Design Thinking. (after all its moral obligation when you learn from the best - Stanford Uni) Pivoted from merger and acquisition to digital transformation to defining innovation strategies to building startup to lean and agile delivery. Always inquisitive by nature and creative thinker in action believe in continuing life long learning journey.

Leave a Reply