Quantifying Defence

Apple PodCast

Spotify

Youtube

AI Generated Summary

This podcast interview from Horangi CyberSecurity’s “Ask a CISO” series features Anant Shrivastava discussing his journey into information security, the move to DevSecOps, quantifying defense, and software supply chain security.

Guest Background

• Anant Shrivastava: 15+ years in information security industry
• Experience: Network security, networking technologies, mobile application security, Linux security
• Open Source: Avid open source supporter, runs multiple open source projects
• Projects: Tamer Platform (Android platform), Code Vigilant
• Communities: NULL (Garage for Hackers), helped establish local chapters (NULL Bopal, OWASP Bopal)

Key Topics Discussed

Journey into Information Security:

Early Years:

• Computers since 2000: Started with Linux more as curiosity and challenge
• School teacher: Said “This is something lot of people don’t know about, but those who know about it are sort of intelligent people in community” - that was challenge where started with Linux
• 2008: Graduated
• Before that: More focused around server administration, management of systems, Linux admin aspects
• First role: Server administration profile
• Bottlenecks: Most stuff in India was managing US servers or servers for US/UK clients - do late night jobs, overnight jobs
• Started thinking: What are other options?
• Most folks around: Moving into programming or leaving IT, moving into non-IT
• Couldn’t leave IT: “It is sort of in my blood, I can’t leave IT”
• Programming: Didn’t want to jump right away as professional career point

Realization:

• Secured servers: Have secured servers, configured servers, worked towards making sure people can’t attack it
• Another side: Around 2010 started popping up - “Hey there is professional requirement of people to break things”
• Interesting: “I’ve been securing, so how can I start breaking things?”
• Started looking: Job opportunities
• Initially: Did not directly start with pentesting as security field
• Joined company: Doing log review and log monitoring
• 5,000 assets: All sending logs (database servers, firewalls, systems sending firewall logs)
• Job: Ensure nothing bad is going on
• Encountered correlation: Very interesting aspect - able to successfully correlate things like by looking at web firewall log, can tell which machine is infected with malware or trojan
• Weird correlations: At that time helped do proper inventory of system
• 2010-2011: First moved into pentesting role
• Started looking at: Web applications and networks as pentesting target

Mobile Security:

• Developed as skill: On own as side hobby
• 2010: Got first Android device - “Okay this is fun device to have”
• Backtrack: At that time Backtrack used to be there
• First person: To port Backtrack image - Backtrack at that point released version for only specific Motorola Android device, no other Android device supported
• Very minor configurational flaw: Was first person who corrected that flaw, got it working on mobile devices/normal phones
• Point onwards: Fun journey with pentesting, breaking systems
• 2015-2017: Started pivoting - “Hey I’m not only going to break things, but I also want to secure things, I also want to help people get security angle right”
• Previous experience: Has been helping

Journey Summary:

• Started: Dipped toe in blue (defense)
• Moved: Right into red (offense)
• Backtracked: Back and became purple (both)

Why Not Programming:

• Not exactly anything in particular: But more of server admin or playing with whole environment, having control over environment was something craved for
• Even when say attacker or purple teaming: “We are people who have sort of control or visibility over entire environment”
• Programming at that point: Roles able to get was more around “You will be responsible for writing this one part of very big module, not even whole program”
• Siloed nature: More of big picture thinker - “I need to see what whole picture is, then even if means need to work on small thing, need to know whole picture”

Move into DevSecOps:

Starting Point:

• Fun coincidence: Back in previous role doing lot of pentesting work, also delivering training sessions
• NotSoSecure: One of prominent Black Hat trainers - used to teach infrastructure, web application, cloud security trainings
• Stuff that irritated: Pentester basically tells you there are problems, would not have clear-cut solution to problem
• Most reports: More of around “Hey you need to read your documentation” or “You need to figure out company policy how you want to fix that thing” - “We are not going to give you recommendation”
• At one side: Good because not taking responsibility on yourself and screwing it over
• But also: Coping out
• Gap looking at: “It does not sit well with me that hey why can’t I actually be in position where I help people actually fixing this also”

Company Acquisition:

• 2018: Company got acquired by Claranet
• Because of acquisition: Now part of bigger set
• Other part of equation: More around blue teaming (not exactly around routinely), they were more around deployment and application development
• Did not have: That kind of security side of things
• Going to bring in security: Internally would have to teach them how to do things
• That’s where: “Okay now I can cure my itch” - itch being able to solve people’s problem

Hollow Flake Quote:

• Hollow Flake: Another prominent personality in infosec did keynote in Black Hat Asia
• Quote resonated: “The offensive problems are technical in nature, the defensive problems are political in nature”
• So true: Pentesters find technical problems, say “Okay well you need to make these changes in these configurations” - once ask for permission, someone says “Well it works way it is, don’t change it” or “We will accept risk, just don’t change way it is”

Journey:

• Those two things: Kind of leading for starting into journey
• Leverage all: What learned in entire time span
• Even though doing offensive work: Even though doing all stuff on red side of things
• Since 2007: Been maintaining own servers - all projects talked about been self-hosting from that time onwards
• Always been in touch: With admin side of things
• Easy time: To say “Okay yeah this is attack part, this is defense part, let’s just start merging them”
• Cloud helped: Whole journey of moving infrastructure to infrastructure as code has been instrumental part of DevSecOps paradigm

DevSecOps Should Not Exist:

• In one of talks: About DevSecOps, this is how actually started - “DevSecOps is term that should never have existed”
• Should never exist: Because DevOps should be secure, should be secure by default
• Goes back: To another buzzword “secure by design”
• Market cycle: Market needs new buzzword every few years (Generative AI right now)

Quantifying Defense - The Battle for Budget:

Another Angle:

• Lot of people miss: There’s another angle
• Offense is measurable: Defense is not
• Measuring lack of something: Exactly
• Offense has done brilliant job: Marketing has done brilliant job of conveying fact around that “If you see that you are not hacked, you just don’t know that you are not hacked”
• Brings whole curtain down: On defense part
• Larger extent: At lot of places faced resistance (5-6 years before this time frame)
• People were like: “Okay what’s worst that can happen?”
• If look at it that way: Entire infosec industry would have to take reality check on it
• Stock market: Does not care about security - prices go down for 2 days, come back up, companies still functioning
• Can keep quoting: Companies that shut down, but very small percentage of companies big enough that got shut down because security incident

Cost Calculations:

• Other problem: “Hey worst case scenario if have to pay fine, if have to pay all customers something, what is that cost?”
• Sat through calculations: People like “Okay what is total cost of breach that can happen?” then calculate “What’s cost of investment in defensive tooling?” then “Yeah we’re okay paying that cost”
• Or they’ll say: “I’ll just get cyber insurance”
• Things started to change: With insurance also mandating and saying “Hey if breach is because of negligence, we are not going to compensate”
• Makes sense: Car insurance makes sure you have brakes, airbags - doesn’t make sense get insurance that insurer would underwrite if don’t protect yourself, don’t do due diligence

Rise of Cloud and Open Source:

• Combination of multiple things: On one side rise of cloud came into picture
• Gave access: To resources which were not in reach to normal people, normal developers
• Parallelly: Whole “as code” movement (containers, virtual machines becoming part of equation)
• Movement around: Giving recognition to free softwares
• Startups realizing: “Hey even if don’t succeed or survive for very long time, code will survive” - open sourcing code bases
• What happened: Reasons why people were not investing in security - one of most prominent reasons was tooling is all proprietary, going to be vendor locked in, tooling costs arm and leg
• With open source tools: Lot of it can be homegrown, lot could be home-managed
• Movement took place: “Yeah now it is possible to actually hire few people, give them mandate to work on things, don’t have to work from scratch on everything, there are open source tools available, use those tools, build basic setup, then moving into better position”

Journey Progressively Improving:

• Initially days: Answer would be “No” on face - “It’s too much costly”
• Now: More of like “Hey is it fine if able to hire two people, would they be able to manage it? Because we do want it, but can two people manage it? Can three people manage it? What is number which need to manage that?”
• SaaS movement: Although at times feel like SaaS is way to go to begin with (like cloud)
• When company starting: Should go for cloud, get bearings right, get to point where cloud becoming costly, then move into own data center
• Same journey for SaaS: Companies starting up should actually just plug into SaaS systems, get bearings right, get business running, once kitty is full, money coming in, slowly move SaaS back into in-house team
• Because ultimately: Will be making decisions for yourself
• SaaS system: Would be making decisions for all customers - cannot have very focused, pinpointed
• Lose good amount: Of control over essentially fate of product

No Upper Limit to Loss:

• 2020, 2021, 2022: Every year get bigger and bigger loss numbers
• Frustrates: To see leadership doesn’t see there’s actually no upper limit to how much can lose
• More customers have: More can lose
• Cyber crime/breaches: Back in day hackers used to just do it for fun, see if could do it, see if could break it, also activists trying to put message out there
• Today: Hacking is industry, it’s business, it’s all about making money (if not about geopolitics, it’s about money)
• Organization: More customers have, for hacker that means more money can make, more money can lose
• As industry: Haven’t yet illustrated this part of formula to leadership enough that there’s actually no upper limit to how much could lose

Distinguishing Terms:

• Distinguish between: Corporate side of hacking versus fun and creative side
• Use term infosec: To represent anything related to job, related to making money with it
• Hacking: Something where basically just having blast

Quantifying Defense:

• Problem trying to solve: How do you quantify? How do you put number to situation?
• Seen frustration: With lot of peers also
• Growing up with community: Had very good effect - NULL community associated with since 2010 (about 12 years now)
• Most peers: Who basically started at that level now are either head of product security, or CISOs, or people with decision-making power, people responsible to product security at certain level
• Not first generation: Probably second generation of cyber security professionals
• When started out: Early 2000s (both came into game) - didn’t care about money and bottom lines, just learning things, building or breaking things, never even thought about having to explain why this is important to anybody
• Now here we are: Now CISOs, heads of product, heads of departments
• Now having: Being faced with this problem
• That’s why: Solution, clear-cut solution has not emerged yet
• Our generation: Who have come up through ranks are just now picking up problem
• Just now picking it up: Saying “Okay we know what value of this thing is, we know it’s valuable, we know we’re not guessing it’s valuable, but they’re not up there, they’re not seeing it - what’s missing?”
• That’s how solve problems: But problem is we’re just picking it up
• Optimistic: Sometime in next 5 years someone among us will figure out how to communicate it better
• Better than: “Oh this is cost of breach” (usually how communicate it with scare tactics)
• Can quantify attack: But can’t quantify defense
• Think going to learn: How to quantify defense in future
• Physics analogy: Look back in day, talking about Higgs Boson particle, figuring out dark matter
• In our industry: That’s big thing everyone’s facing - how do we quantify defense? How do we communicate value?
• These are two things: If somebody among us figures it out, going to change game

Mindset Change:

• Another angle: More of mindset change all of us will go through
• Analogy: Painting versus medical profession
• Medical is science: Because there’s method to whole madness, set procedure everyone has to follow, leeway people can take but procedure everyone has to follow
• Painting is art: Everyone does it way they want to do it
• Infosec right now: Sits more in art category than science category
• More move infosec: From art to science, more will be in position to measure something, position to actually get most benefit out of it
• Medicine: Can use metrics to communicate to non-medical person “This doctor is good, that doctor is not”
• Looking for: Road to turning information security into actual science

Software Supply Chain Security:

Why Worry About It:

• Non-software example: If food to be made at house, all ingredients have to be bought from market
• Vendor in market: Sells you all ingredients
• Ingredients not created: By that vendor - actually sourced from someplace else
• Whole chain: Goes in
• COVID example: When COVID struck, people not able to find stuff at local shops because transportation not working, big wholesalers not able to send stuff to local retailers - chain breakage
• Whole chain: That exists which takes stuff from fields to house is supply chain
• Put that example: Into software development life cycle

80% Import Statements:

• By own matrix: May be wrong but assumption and observation so far
• About 80%: Of what call software products right now are basically import statements which are calling in stuff other people have done
• Somebody else built: Yes
• 80% of product: Actually developed by someone else, using that stuff
• Modularization: Of programming language gave flexibility where can write something, everyone else can use it
• Originated from: Unix philosophy of doing one thing right, then chaining multiple programs together to get right outcome
• Best example: curl - right now in every single place where human has ever touched (Mars, Apollo, any space media, any media gone into undersea environments, curl has been there)
• Software component: Needed by all other tools to get some job done
• All these ingredients: Part of software supply chain because components forming whole equation

Why Care:

• Just like: Cannot pick food item from street randomly lying around, using it
• Need to be aware: What digesting, what ingesting first, rather not even digesting what ingesting first
• Whatever components importing: Should be aware what they are, where coming from

Initial Days:

• Very few people: Used to do open source
• Very small number: Of publicly available modules
• People struggling: To find public modules
• Somewhere down line: People got idea “Hey if put code in public, would get recognition”
• Recognition could equal: To job, job could equal to stable life for myself
• Lot of people jumped: Into open source
• Right now: If look at college students, lot get input “Hey if want to do something in tech, make some projects open source, put code out so other people can see”
• But what that also does: There is lot of publicly available code which does not have any intentions of being maintainable, which does not have intentions of being continuously worked on
• When looking: Trying to find module to use, may end up finding it, may end up using it
• If bug comes: In that code, not even aware bug exists in that code, can cause problem

How to Secure Supply Chain:

Three Aspects:

1. Need to know what using: There has to be way to track what is it that constitute as components in environment - points to keyword “SBOM” (Software Bill of Material)
   • Just like: When go to carpenter or storekeeper, say “I want these” - give list of items
   • Software Bill of Material: List of items that are part of software stack
2. Should be able to query database: Which has list of vulnerabilities
   • Databases: Like NVDs or local country-specific vulnerability database might be there
   • Query them: Find if existing flaws in those components
   • Covering: From situation where existing bugs are covered - not using something already vulnerable
3. Put money where mouth is: Because product giving value, should be taking portion of that value (not talking about huge percentages, maybe 2% of profit), put that as push back to open source communities
   • Use fund: In maybe two different manners:
     • Directly support developers: “Hey you developing something I’m using, here is donation, ensure food on plate, in position to work on things”
     • Contract with developer: “Since developing component for me, going to pay small sum (not life-changing sum), ensure recurring sum goes to you because work important to me”

US Government Initiatives:

• 2021 end: US president gave declaration/statement saying “US government needs to be cautious about software supply chain”
• SSDF framework: Came into picture - NIST developed SSDF because of that
• Just recently: Three or four days back another public statement around cybersecurity
• Very interesting line: To effect what saying was “It’s not responsibility of open-source developer to ensure code is secure, rather it’s responsibility of party which is getting benefit out of it to ensure components are secure”
• Totally on point: Right on nose

Developer Reality:

• Lot of developers: Don’t actually do this for money - do it for joy of creating
• To ask somebody: Who created something 5 years ago to stay maintaining it even if pay them, they will not do it because moved on to other projects more interested in
• Fun example: Very recently lot of movement from Twitter to Mastodon
• Prominent client: Called Pinafore (P-I-N-A-F-O-R-E) - single page web application, can go to website, login into environment (not logging into website), all work happening in browser, all JavaScript based, works as brilliant client
• Moment Mastodon got popularity: People started raising issues in repository “Hey we want this, we want this, we want this”
• Immediate reaction: “Hey you know what? I developed it because wanted to do it, not for you, don’t want to take burden, closing chapter”
• That’s rule not exception: Most developers do not want to sit there, continue to work on same project for 10 years
• Bitcoin example: Programming team behind Bitcoin - four or five of them tend to Bitcoin, but consistently have to change roster because programmers get burned out, don’t want to work on it (Bitcoin probably one of most prominent things could be working on today, to be one of five people tending to it is big deal, but even to them not something want to stay doing forever)

Other Approaches:

• Amount talking about: Reserve some amount - one of ways is actually incentivize developers, existing developers
• Other approach: Something tried in previous organization - reserve time of own employees to work on those projects
• Ensure: Put code back, put contribution back, help them back, maybe find bugs, fix those bugs for them
• Contribute: Instead of just being on sideline, be part of that ecosystem

SSDF and Frameworks:

• Another thing run into: Being information security professional, when have to deal with programmers, developers
• US put out SSDF: Microsoft put out SSDLC decade and half ago (long time ago)
• Yet: Lot of clients work with, lot of them are dev houses
• Couldn’t pay them: To follow framework
• Understandably: Because have deadlines, have sprint, have to ship code
• Security takes backseat: Said so many times on podcast
• Little skeptical: About what SSDF will do unless has teeth
• Teeth right now: “If don’t follow SSDF, cannot be contractor to US government”
• SSDF is cascading requirement: You as vendor needs to follow it, your vendors need to follow it, their vendors need to follow it - that’s teeth that exist
• Hope it works: That’s hope
• Even if doesn’t work: Means me and you still have jobs, so guess that’s okay too

Supply Chain is More Than Modules:

• One more thing: Lot of people don’t understand or realize about supply chain
• Talking about ingredients: Focused on ingredients, not focused on fact that if truck is not moving, ingredients can’t move
• Supply chain is not just: Modules importing
• It’s the IDE: Using
• It’s third party SaaS library: Using
• It’s person sitting: Somewhere in distant country managing IAM policies for you
• They also come: In supply chain problems
• All of that: Has to be taken into consideration because all combined together giving final product
• Any screw up: At any level
• SolarWinds example: Don’t know if final verdict, but chain of event aware of has been:
  • Breach at JetBrains
  • Led to implant in one of their code software
  • Deployed into SolarWinds
  • Allowed attacker to plant backdoor into Orion servers
  • Planted into other Fortune 500 companies
  • Backdoor then executed
  • Not even direct attack on Fortune 500
• Perfect combo move: A lot call it that - just chain that led to that, started with flicker (everyday thing for something like JetBrains to get breached), but led to crazy consequence
• Goes back: To original point - there is no upper limit to what breach could cost
• No upper limit: To what breach can cost
• Other points: Making few minutes back - because in zone where it’s art and not quantifiable, no one knows when to start, when to stop, how much to do
• That’s where: IT security always going to take backseat
• Assure: “50% of secure setup or 70% of secure setup, if give me more time can do it more”
• To what percentages?: That’s right
• If can build that: People would be happy to put that
• Right now: It’s all ballparks, all just guessing
• All kind of: Having to deal with it on that level until somebody (like said) comes up with way to turn it into science (like said)

Last Thought:

• For offensive people: Start toning down expectations, start looking at other side, making judgment calls that “Hey what think as super critical may not even be required to be implemented from dev’s perspective”
• For developers: Start ranking up bugs - “What think is not problem at all because going to decommission it in 2 months” - listen to what other person saying, meet middle grounds
• Meet in middle: That’s last thought

Key Insights:

• Journey: Blue → Red → Purple (defense → offense → both)
• DevSecOps should never have existed - DevOps should be secure by default
• Offense is measurable, defense is not - major challenge
• Offensive problems are technical, defensive problems are political
• Need to move infosec from art to science
• 80% of software products are import statements
• Supply chain is more than modules - includes IDEs, SaaS libraries, IAM policies
• Need to quantify defense and communicate value better
• Open source tools made security more accessible
• SSDF has teeth - can’t be US government contractor without it

Actionable Takeaways:

1. Offense is measurable, defense is not - need to figure out how to quantify
2. Move infosec from art to science - need metrics and procedures
3. Offensive problems are technical, defensive problems are political
4. 80% of software is dependencies - need SBOM
5. Supply chain includes more than code - IDEs, SaaS, IAM policies
6. Put money where mouth is - support open source developers (2% of profit)
7. Reserve employee time to contribute to open source projects
8. SSDF has teeth - cascading requirement for US government contractors
9. Meet in middle - offensive people tone down expectations, developers rank up bugs
10. Need better communication of security value to leadership