Cybersecurity incidents continue to increase exponentially across engineering organizations and it seems this rise is less about technology solutions and more about ineffectiveness of risk management programs. While security practitioners in technology organizations often have a good understanding of technical issues causing organizational risk, many don't have the relational skills to collaborate and drive change needed to improve the organization's risk profile. This leads to flawed programs. If security teams want to build effective programs that reduce the negative impact of security vulnerabilities and data breaches, they must learn to meet software development and engineering teams where they are through more collaborative processes. Restorative practices could provide a framework through a set of techniques that would foster a relational culture to support the organizational change efforts in managing risk. By partnering "with" development and engineering teams, security practitioners could work more supportively and embed themselves into the overall software development and operational lifecycle. By operating as collaborative partners, security, engineering and development teams are empowered to resolve conflict and add value to the business portfolio through less operational friction. This transforms the security professional's role from the organization naysayer into hero.
Reimagining Risk Management: How Restorative Practices Can Transform Information Security Programs
1. Reimagining risk management: How
restorative practices can transform
information security programs
Michele Chubirka
2. • Michele Chubirka, 20+ year
technologist working as a cloud
security advocate at Google.
• Creator of the Healthy Paranoia
Security Podcast.
• Analyst, architect, researcher, writer
for Dark Reading, Information Week,
Network Computing, and Tech Target
• Focus on security architecture and
“best practices.”
• Views are my own.
http://postmodernsecurity.com
@MrsYisWhy
Who Am I?
Who Am
I?
6. What is risk management?
RISK =Threat x vulnerability x impact
According to the National Institute of
Standards andTechnology (NIST) SP
800-37 Rev. 2, Risk Management is
“The program and supporting
processes to manage risk to agency
operations (including mission,
functions, image, reputation), agency
assets, individuals, other organizations,
and the Nation, and includes:
establishing the context for risk-related
activities; assessing risk; responding to
risk once determined; and monitoring
risk over time.”
13. Compliance as
Property
• In technology and software engineering, a
common approach to security is to address
requirements after delivery.
• This approach fails to consider how the
requirement(s) can be integrated during
development, which avoids reengineering later.
• Disempowers engineering teams by
outsourcing compliance and the
understanding of the requirements to another
group.
• To proactively address security concerns, a
team must see these requirements as their
“property” to address them efficiently during
the design and development phases.
14. Security is a
social problem
Most practitioners treat risk
management as a technical problem
It’s really a social problem.
Diverse groups are involved in the risk
management process. To be effective,
we need to cultivate relational skills to
support collaboration.
We spend Billions of dollars on security products and at the end of the day, the weakest link is people
Even with training, people often make the wrong choices.
Everything is at stake for us, but too often behavior is siloed and people don’t work together.
Security is a social problem.
Something isn’t working.
What is a data breach?
A data breach is a cyber attack in which sensitive, confidential or otherwise protected data has been accessed or disclosed in an unauthorized fashion. Data breaches can occur in any size organization, from small businesses to major corporations. They may involve personal health information (PHI), personally identifiable information (PII), trade secrets or other confidential information.
We spend Billions of dollars on security products and at the end of the day, the weakest link is people
Even with training, people often make the wrong choices.
What if the problem isn’t about the user at all, but security practitioners?
Everything is at stake for us, but too often behavior is siloed and people don’t work together.
Security is a social problem.
Proactive planning and response.
Identify the Risk – what’s the type of risk?
Assess and measure the Risk – use formula, identify impact
Manage or Rank the Risk – use risk tiers and score (qualitative or quantitative). Will you accept, transfer, reduce risk? What are the mitigators/controls in place? Reduce the risk, can’t eliminate.
Monitor and report– how are you managing the risk over time? track over time. Audit controls.
Typically, the relationship between risk management professionals or security practitioners and technical staff (software developers, systems administrators) is authoritarian and adversarial as illustrated by the Social Discipline Window. There is a technical shortfall that increases organizational risk and a report is provided to a team and their leadership that calls out the gap. There is a defect management service level agreement (SLA) which mandates a deadline for remediation and there isn’t much of a discussion. It is rare to see empathy and understanding. While it’s important to address security vulnerabilities to protect an organization and its customers, the standard approach is coercive, unidirectional and grounded in punishment and professional shame.
This approach results in the interruption of positive affect or shame, embarrassment and humiliation.
Now you have an entire organization stuck in a shame response. The security and risk practitioners don’t understand why they aren’t making progress in burning down security issues, because they think it’s just a technical issue and that the technical staff is being intentionally obstructive.
What techniques from the restorative continuum could we use in risk management?
Affective statements with technical staff to discuss the issues and the impact to ourselves and the organization.
We could use affective questions to understand the impact to a technical team’s workload and priorities.
We could use impromptu conferences to resolve conflict or proactively build relationship.
We can use circles to develop collaborative approaches, for problem solving or to facilitate creative solutions.
Most importantly you can integrate the three ”E’s” of fair process, engagement, explanation and expectation clarity.l
With apologies to Nils Christie, I’ve borrowed and repackaged his original idea of conflict as property for information security.