3. Why are we here?
• IT is changing fast. Attackers are changing fast. Defenders don’t.
• Security tools must change
• Security processes must change
• Security practitioners must change
19. The New Practitioner
• Influence design, architecture
standards, processes
• Automate tasks
• Forensics
• Security assessments
• Identify gaps and recommend fixes
• API integration
• Data science
• Routing, load balancing, nw protocols
The Traditional Practitioner
• Monitoring security alerts
• Manage network security
• Manage endpoint security
• IR/Forensics
• Pentesting
• Vulnerability Scanning
• Policies/Standards
• Compliance/Regs
• Log management
• DR/BCP and SecAware
The Security Practitioner: old versus new
20. The New Practitioner
• Influence design, architecture
standards, processes
• Automate tasks (code)
• Forensics
• Security assessments
• Identify gaps and recommend fixes
(code)
• API integration (code)
• Data science (code)
• Routing, load balancing, network
protocols
The Traditional Practitioner
• Monitoring security alerts
• Manage network security
• Manage endpoint security
• IR/Forensics
• Pentesting
• Vulnerability Scanning
• Policies/Standards
• Compliance/Regs
• Log management
• DR/BCP and SecAware
The Security Practitioner: old versus new
21.
22. Understanding security’s role by
understanding IT
Traditional approach to security:
• Security is always a secondary or enabling layer
• Security must have direct knowledge and experience
with the underlying layer in order to be effective at
protecting it or recommending feasible solutions
• Direct experience in core technical disciplines goes a
long way in earning respect and cooperation
Physical
Security
OS
Layer
Network
Layer
Service
Desk
Dev, QA,
Test
Web/App
Layer
Ops
23. Understanding security’s role by
understanding IT
Issues with the traditional approach:
• Few security teams can ever be ‘well-rounded’
enough
• Security team isn’t qualified to advise much of IT
• Adversarial/dysfunctional relationships common
• IT changes often; attackers adapt quickly
• Defenders and security tools adapt slowly
Physical
Security
OS
Layer
Network
Layer
Service
Desk
Dev, QA,
Test
Web/App
Layer
Ops
24. Security
Security’s changing role
An example: going ‘cloud-first’
• Lower-level IT layers are outsourced
• Most security practitioner knowledge lies in these
layers
• Infrastructure-heavy security skillsets lose value
• Concept of bi-modal IT further confuses things
• As IT changes, so must security
Physical
Security
OS
Layer
Network
Layer
Service
Desk
Dev, QA,
Test
Web/App
Layer
Ops
25. Security’s changing role
Cloud and DevOps – an opportunity to redesign
security:
• Smaller ‘well-rounded’ groups
• Dev, ops, infrastructure and security roles are shared
• Everyone working towards a clear, common goal
• Relationship between security and developers is
crucial
• Security can’t impact delivery schedule
Physical
OS
Layer
Network
Layer
Service
Desk
Dev, QA, Test;
Web/App Layer; Ops
Security
26. Questions
What should security’s future role be?
• Security is redistributed into IT for all operational tasks
• Dedicated security staff performs
• high-level design, design/architectural input
• monitor changes in risk/attackers/landscape
• instruct/consult individual SMEs as needed
Physical
OS
Layer
Network
Layer
Service
Desk
Dev, QA, Test;
Web/App Layer; Ops
Security
SME
Internal Security Team
Security
SME
Security
SME
Security
SME
27. New rule: if you own it, own it
“Whomever is responsible for an asset – be it data,
infrastructure, code, or people – must secure it”
28. Why make asset owners responsible?
• No one knows and understands the opportunities, constraints and
dependencies of the asset better
• Security becomes a bottleneck for performance, progress and often, even
security
• Little to no time wasted on remediation conflict: what to fix, how to fix it,
when and at what priority level
• Likely that fewer security issues will occur*
• Drives the cost of securing systems down, in terms of labor, efficiency and
efficacy**
* I’ll explain later
** I’ll explain after that
29. Better Testing, Worse Quality?
Study done in 2000 by Elizabeth Hendrickson
Reads like a short
version of the
Phoenix Project
30. Better Testing, Worse Quality?
Study done in 2000 by Elizabeth Hendrickson
• Creating an independent testing group can encourage counterproductive culture
• “Don’t do today what you can push off onto someone else’s plate”
• Document and address low hanging fruit
• Schedule time for developers to test and fix bugs
• To improve code quality, stop the problem at the source
• Everyone should understand what they’re building and why
• Get testers involved earlier in the process
• Bottleneck testing resources and developers are forced to ship higher quality code
http://testobsessed.com/wp-content/uploads/2011/04/btwq.pdf
31. Better Testing, Worse Quality?
Study done in 2000 by Elizabeth Hendrickson
• Could this apply to InfoSec?
• Surely not.
• In fact, it might be quite worse.
• We’ve convinced everyone not
just that security is our job, but
that we’re the only ones that
can do it properly.
• What if they believed us?
Editor's Notes
Just read the tweet.
DevOps is a combination of culture, processes and principles.
This is the most challenging aspect of what we’re talking about today, because it fundamentally transforms how IT works
And ultimately the combination of DevOps and new technologies like cloud are having a permanent impact on how businesses operate.
Speed: First production release going out in the time it took hardware to ship to our doorsteps
Agility: The ability to add/remove/change infrastructure at will without significant capital expense
Resilience: Could also be thought of as “survivability”. With this much automation, the application must be resilient, and IT must plan for a range of contingencies. Bonus: you’ve planned for DR/BCP simultaneously!
Success
Why DevOps? It isn't a fad, it is simply the most efficient, reliable and successful way we've found so far to build and run software.
In the beginning, IT led the charge as an experiment and a way to fix/alleviate issues. Now that the business has seen the value in it, it has gone from fad/trend to requirement and permanent change. There’s no going back.
I'm talking about people, but this is all text, it's a list
Focus on the message - again, try to use icons
Right now, the slide doesn't show the differences very well
Don't necessarily need to use the lists
Could ask the audience what differences they see, and then reveal the actual differences - look at how diff tools show the difference visually
I'm talking about people, but this is all text, it's a list
Focus on the message - again, try to use icons
Right now, the slide doesn't show the differences very well
Don't necessarily need to use the lists
Could ask the audience what differences they see, and then reveal the actual differences - look at how diff tools show the difference visually
We could also throw some other things in here as well.
People (security awareness training)
HR
Data
Supply Chain/Third party partners
Compliance/regulation
Design/Architecture
Identity
We could also throw some other things in here as well.
People (security awareness training)
HR
Data
Supply Chain/Third party partners
Compliance/regulation
Design/Architecture
Identity
We could also throw some other things in here as well.
People (security awareness training)
HR
Data
Supply Chain/Third party partners
Compliance/regulation
Design/Architecture
Identity
We could also throw some other things in here as well.
People (security awareness training)
HR
Data
Supply Chain/Third party partners
Compliance/regulation
Design/Architecture
Identity
Just an idea – doesn’t have to be precisely like this. Depends on the business, the culture, trial/error and a hundred other factors. The general idea though, is to get security responsibility and expertise closer to where the work is done.
Introduced an independent test unit, which made the number of bugs go up and software quality go down.
Findings
More QA = more bugs and longer cycles
Created the psychological impact of telling developers that quality is someone else’s problem
Insulting; percieved lack of empathy and respect for the developer
Solution
Tight relationships necessary between QA and Dev
QA remains, but with an artificial bottleneck
Developers still responsible for deadlines and therefore have to ‘budget’ time for QA
Devs write better code to ensure it goes through QA quickly
Devs need to be given 10% extra time to ensure better quality code.
Also, remember – the two are inseparably linked. When we talk about code quality, we’re also often talking about security - issues with quality is where vulnerabilities come from, right?