Shift Level with CISO’s

AI Generated Summary

This is a Snyk panel discussion on “Shift Left Strategy with CISOs” featuring Anant Shrivastava (Technical Director, NotSoSecure) and Patrick Pachapa (Director of Information Security and Risk, Altia Group), moderated by Vandana.

Panelists

• Anant Shrivastava: Information security professional with 12+ years corporate experience, expertise in network/mobile application/Linux security, Technical Director for NotSoSecure Global Services, speaker/trainer at various international conferences (Black Hat USA/Asia/EU, NULLCon, KOKON), leads multiple open source projects (Android Tamer, Code Vigilant, Hacking Archives of India)
• Patrick Pachapa: Graduated as Electronics and Communication Engineer in 1995, moved into IT in 1997, 24 years experience covering all aspects of IoT infrastructure and security, currently Director of Information Security and Risk at Altia Group (Middle East-based retail franchisee operator)

Key Topics Discussed

DevOps and Security Teams Working Together:

• Still silos: Lot of teams still working in silos, running own projects, separate from main agenda
• CISO’s major aim: Make sure getting integrated - if don’t get integrated, as good as old model
• Conveyor belt analogy: Manufacturing car - team building doors separate from team painting car, work very separately although same conveyor belt
• Old model: Business analysts get requirements, security had nothing to do with it, development teams develop, testing teams come, only after that security teams got involved (VAPT), just before code went into production
• Long list of vulnerabilities: Project managers would fight saying “can’t go live unless fix all these vulnerabilities”
• Still playing out: In quite a bit of places, quite a bit in industry
• Maturity level: Still way off, lot of work to do

Larger vs Smaller Organizations:

• Larger companies: Massive team working on things - when have large number of people inside one specific team, very hard to get them to formulate single team and work as single unit
• Larger corporates: Massive number of developers, massive number of administrators - still operate in own dominions
• Do work together: Nowadays that has been major influence with DevOps - dev and ops work together, but effectively not one single team called DevOps, there are two separate teams (dev, ops)
• Startup world/agile companies: Small number of people, take up both dev and ops responsibility
• Security: Always on edge end of ladder, not too much involved - whole point of keyword “sec” being added into DevOps
• Gradual progress: Stopped treating security as last crying baby who just needs to be satiated, to someone need to talk to, need to interact with
• Boils down to: How do security people interact with anyone else in organization
• If keep attitude: “Holier than thou, I am the one who does everything, anything I say is right” - not going to make progress
• Talk in terms: Of language that people understand - then synergy can actually be created

Handling Relationships:

• CISO as scapegoat: Friend messaged saying “your title says scapegoat” - CISOs are ones whose heads are rolling if there is breach
• Equifax breach: More than 140 million user records stolen, week later CISO was fired
• CISOs raised voices: Why was not head of development fired? These guys write really substandard code, code not secure enough, just put whatever can put together, push into production, don’t even give time to do proper VAPT, proper time to fix it, no attack surface scans, no internal/external simple scans, no cyber scorecard
• CISO gets fired: Because CISO all did was open gate, but stuff was already corrupt/vulnerable
• Mentality has not changed: Much even today in big organizations - CISO ends up making lot of explanation for all that happening (ransomware attack, data breach, something else)
• CISO still gets blamed: Reason telling this is DevOps/DevSecOps is combined responsibility, it’s culture
• DevSecOps model: Security gets involved right there - should be security architect sitting with software architects when requirements gathered, starts there, becomes combined responsibility, team takes blame
• On lighter note: Because of all risk and threats around is why CISO position itself is today existing - unless there is threat, no military required for country

De-risk Individuals, Focus on Collective Responsibility:

• Major problem: Culture
• Focus on one aspect: De-risk individuals, focus on collective responsibility
• If hack happens: Not one person responsible - does not matter if CISO or junior or intern, it’s collective responsibility right from dev to ops to security, all of us have failed in whole process somewhere
• Moment de-risk individuals: Movement there is no question about “hey this happened, who gets to be on crossbow” - when that part out of equation, that’s when people start looking at “okay something has happened wrong, what can we collectively do to fix it”
• Lot of places: Shift has happened, seen result where individuals more concerned about organization, reputation, getting stuff sorted
• Large number of organizations: Where does not happen - individuals more focused on “I want you to sign this particular format of documentation in triplets, CC these five people so that if something happens, I am not on crosshair, someone else gets blame”
• Situation keeps happening: So part about handling relationships

Two Angles:

• One: Right now basically have to deal with organization - “when in Rome do as Romans do” - deal with organization where are, but effectively aim should be to move towards scenario where convince everyone “I am not saying you are wrong, I’m not saying I am wrong, somewhere someone is going to have goof up, when that happens, neither you blame me nor I blame you, we both work towards fixing problem”
• Gets interesting: When dealing with business - question comes “I get all of it, but when something goes wrong, what do I tell my board, what do I tell my investors, who gets to take blame?”
• Education required: “Hey no single person is responsible, it’s collective failure, everyone takes whole blame” - can’t fire entire company, if all of us taking blame and saying “give us few days, taking corrective actions, sorting it out, going to give update on corrective actions” - board should be reasonable enough to understand situation
• If not reasonable: Maybe getting fired might be better option in that kind of scenario

Security People Getting Into Organization:

• Problem seen: Security people get into organization fresh and like “I’m the boss, going to start dictating terms, want to dictate from day one” - not going to work out
• Other people: There in group, been there for some time - respect their experience, understand equation of system, then try and work towards correcting it or aligning yourself with equation

In-House vs Vendors:

• Two categories: Service provider and product provider
• Product provider: Building security products which could be plugged into CI/CD pipeline
• Service provider: Say “okay you can buy this product, but I’ll help you configuring it and getting it into system”
• Suggestion: Look at own scenario - not necessary that buy best and greatest product available in market, large number of scenarios where that product would be useless in specific scenario, specific setup
• One line: “When it’s about general processes we say your mileage may vary, when it comes to DevSecOps your mileage will most definitely vary with every single organization”
• One tool: Friend has used in organization is not going to be directly usable here - have to do lot of testing, correlation checks, balances
• Can delegate: To external vendor to get base pipeline running, get base setup done where at ground level, but need to have team of own, need to have at least very small skeleton crew within organization (no matter how small how big) who understands what those tools are, how they work, how is vendor operating on those tools
• Let vendor deal: If want, or can take everything in house after certain point, but in any given scenario there should be someone within organization who knows what is going on in system
• Right now: Lot of people basically focusing on building own in-house tools because everyone realizing with tools available in market turnaround time is very high
• If run scan: Not going to finish in 15 minutes anyhow - have to write own custom wrappers, write own profiles, get things done in shorter span of time
• Lot of in-house tool work: Going on
• When comes to offloading: To third parties, yes that’s trajectory lot of people following especially organizations which do not have security people in-house
• If vendor: Dealing with that, basically tell them “I’m gonna handle all of it, but can we also get some people on board in your company on your payroll so that if in future I am not there or my company is not there, you are not left in ocean alone to handle all situation”

Skeleton Team:

• Very important: That skeleton team - that team kind of is going to be your own team there, who understand
• Three to five: Whatever number want to have (don’t think should be more than five, then not skeleton team anymore) - three being minimum, five being max
• Team: Will kind of make sure entire loop of DevSecOps is in place, they are ones who are kind of governance team which will be maintaining whole DevSecOps pipeline
• Ideally should be: Sitting under CISO because all said and done DevSecOps major stakeholder is CISO, of course app dev head or development head will also be co-stakeholder, CIO oversees both of them - that’s in ideal world how things will be set up

Shift Left:

• Lot of emphasis: Nowadays, development teams also under extreme pressure to deliver
• Time to market: Phrase came long long time ago, even 20 years ago when with Visa first time heard term
• Old waterfall method: Two releases in year would be great - after every release entire team went out and partied hearts out, came home drunk because that much work goes into whole release
• Today: Having release pretty much every week or every day - think will get to point where will have release every hour
• Releases become so rapid: What call CI/CD pipeline, way things changing
• Shift left approach: Good, unavoidable - writing code, testing, putting through security assessments, releasing code, all has to happen within very very short time
• Movie analogy: Making movie - director, producer, main actors sit, talk about movie, come up with script, start on day, release movie - that’s how used to be in software development also
• Today: Everything intake in terms of making movie has to happen in day - includes recording, re-recording, everything
• Left with no other choice: Than to shift left, start testing whether going to be test-driven development or behavior-driven development (TDD, BDD)
• Bringing tools: Like SAST (static application security testing), bringing dynamic application security testing tools as well
• Large environment: Like Google, Amazon, Microsoft, other big banks - tools must be customized, engineering teams also working closely to customize, put wrapper that Anant was talking about, make sure having tool that is fitting into environment, running tool and it’s as rapid as possible
• Combination: Of business requirement, combination of market requirement, combination of efficiency in which can deliver code - has to be proper code without any blemish, without any bugs, without any vulnerability
• Testing team: Looks for bugs, security team looks for vulnerabilities - now all one in all, like three musketeers “one for all, all for one”
• Three musketeers: Development, testing, security - all working together

Sony Television Example:

• When manufacture televisions: There is no testing because whole automation built into manufacturing of television set eliminates anything that has manufacturing defect or anything not working before reaches end of conveyor belt
• Exactly what talking about: Culture where code is ready, everything built into it, when code ready it is already fully tested and fully security assessed as well
• Become very important: Unavoidable - if don’t adopt this shift left culture, companies that don’t adopt it are going to be left out
• Time to market: These guys will be left behind, competitors will beat them in game, nobody wants that

Security Operations:

• Very important: For any organization
• Incident response process: Deep down goes down into shift left strategy as well
• Question: How do we offload it to third party vendor or do we handle in-house? What’s rationale behind using it? Do we involve security team with DevOps teams or is it okay to leave it with security operation center team like SOC team?
• How handle: Because when comes to fixing bugs it again boils down to coming to operations team, to development team

Key Insights:

• DevOps and security teams still working in silos - maturity level way off
• CISO as scapegoat - Equifax example, CISO fired week after breach
• De-risk individuals, focus on collective responsibility
• In-house vs vendors - need skeleton team who understands
• Shift left unavoidable - releases every week/day, maybe every hour
• Sony television example - automation eliminates defects before end of conveyor belt
• Security operations - how offload to third party or handle in-house

Actionable Takeaways:

1. DevOps and security teams still in silos - lot of work to do
2. CISO as scapegoat - Equifax example, CISO fired
3. De-risk individuals, focus on collective responsibility
4. Respect experience of people already in organization
5. In-house vs vendors - need skeleton team (3-5 people) who understands
6. Shift left unavoidable - releases every week/day
7. Tools must be customized for large environments
8. Sony television example - automation eliminates defects
9. Security operations - how offload or handle in-house
10. Three musketeers: Development, testing, security - all working together