Every week, Sprocket Security CEO Casey Cammilleri interviews an expert leading the charge on empowering security experts and practitioners with the knowledge and insights needed to excel in the future of cybersecurity.
He recently spoke with Parthasarathi Chakraborty, Former Deputy CISO at Natixis. Here are the top takeaways from the interview.
#1: Stop Building Security Architecture in an Ivory Tower
“In some organizations, when it is a larger organization, architecture means, number one, a larger team and more structured documentation. And in some cases the documentations, to be very honest, are like putting you in an ivory tower. You come up with great visual diagrams, PDFs, and PowerPoints, which is too good to be true, like a real-world scenario.
“And then you hand it over to your engineering partners, your operation partners, and they said that this is not a great use to me because it is not related to the ground reality. You are asking me to build something where I don't have the foundational maturity in my organization. So in larger organizations, architecture had a lot of structured documentation, SharePoint or a Confluence website.
“In smaller organizations, not so structured, the information was there in some shape and form, but did not have that much of a method or even process or procedure, metrics, and reporting. So it varies depending on the organization size. But one thing that is common that I have seen in larger organizations or even smaller organizations is, in order to have a checkbox. Do you have a security architecture function? Yes. Most of the companies have it. Even if they don't have it, right now they're building it.
“But if you ask them how effective is your security architecture function, can you tell me, if you take me to production, can you tell me one of your current implementations is exactly following the guidelines given by your architecture, how you prove the efficacy and the effectiveness of the dollars spent in the architecture function? Every company I have seen struggled. So I do have a function, but I cannot basically tell how much of that is properly utilized and how much value I'm getting out of it or how much I am out of compliance from what architecture tells me to do.”
Actionable Takeaway: Beautiful PowerPoint diagrams and Confluence sites mean nothing if engineering teams can't implement them. Most organizations have security architecture functions for compliance checkboxes, but struggle to prove actual value. Test your architecture's effectiveness by walking into production and finding implementations that actually follow your guidelines.
#2: Keep Security Architecture Simple or Engineers Will Bypass It
“I tell all my students all the time that whatever you build, the very first thing for a sustainable architecture or engineering is keeping it simple not to over engineer something. Do not build overly complicated controls which is beyond your business objective or your risk appetite. And also build something which is absolutely relevant. I should not have a dream that, “Let's make the life of the developers complicated tomorrow. So let's come up with some security architecture with 20,000 complicated controls. Surely they're going to bypass it, they're not going to implement that.
“So the first thing we need to do is work with your governance, risk, and compliance team. Look into your organization's high-level policies and standards. So because if you comply with your policy and standard, then indirectly, depending on the industry, whether it is a FISMA or it is a HIPAA, or if it is a high-trust boundary, or if it is an NYDFS requirement or FRB requirement, you just name it any regulation authority or any ISMS framework, you'll be compliant because those requirements were taken into account when the policies and the standards were created by the compliance team.
“Now, if you have a mature governance, risk, and compliance practice, then that becomes one of the input for your reference architecture or design pattern. You must ensure that you are following the policies. If policy says you need to have a privileged access control system, your password must rotate in 30 days or if you need to have a 16-character password that never rotates, you must implement that.
“Now that is only one input. In some cases the governance, risk, and compliance policies and procedures are not very mature. Then it becomes a partnership. You work with your peers in the GRC team and collectively you build something, ‘Hey, I think this should be incorporated as our policy because this is of the regulation and the industry best practice,’ and all those stuff. But taking just the policies and standards is only solving a piece of the puzzle. Because our friends on the dark side, they don't read our policies and procedures to attack us, they basically try to punch us hard wherever they find the weakest link in our system.”
Actionable Takeaway: Sustainable security architecture starts with simplicity and business relevance. Partner with your GRC team to build on existing policies for regulatory compliance, but remember that attackers don't read your procedures. They exploit weaknesses regardless of documentation, so balance compliance requirements with practical implementation reality.
#3: Mine Your Red Team Data Before Building Security Architecture
“The very first thing is that when I take over my new responsibility in a new organization, I look for any existing report, be it audit or pentesting or red team or the big four consulting. I mean most of the time you will find that there was a consulting engagement to identify the SWOT analysis — strength, weakness, opportunities, and threats — or something. Or a NIST assessment was done and these are the red and yellow areas. So that becomes the first input.
“I at least have something to know, okay, my identity practice is not good, then as I said, building the partnership, working with the red team, the pentesting team, the security operations team. Because the moment you engage your red team, they eventually find innovative attack patterns to break your system. But there are some basic things they try in every single organization: are these ports open? Is the access there? Is lateral movement easy? Is the exploit available that I can literally move, use that exploit, and then escalate my privilege and do something. So I talk to them and try to understand. Show me the last six months or one year red team assessment, what are the common themes and patterns that you found?
To be very honest, they appreciate it. It's not that I'm trying to make their life difficult. They want — they basically come and tell, “Hey, these are very basic things.” And I'm able to like, I want to do a better job. I want to think even beyond those basic things and come up with innovative ideas to break, but I'm finding those easier avenues so I collect those information from them. What are the top 10 things you are finding again and again? I want to at least block those things and ensure those are repeatedly in a consistent manner implemented through my architectural design pattern.
“Same with security operations, the trend data. Maybe we find some of the vulnerabilities existing and then when you do a deep dive into a root cause analysis, you find that the team that is doing the terraform implementation when it comes to cloud, they are probably missing something. And they're probably missing something because there was not a clear instruction from an architecture or a blueprint perspective that you must do this.”
Actionable Takeaway: Start new architecture roles by collecting existing assessment data from audits, penetration tests, and red teams. These teams repeatedly find the same basic vulnerabilities because clear architectural guidance is missing. Partner with them to identify the top attack patterns, then systematically address these gaps in your design blueprints.
