Five questions with IANS Faculty member, Ian Amit
This is part of our ‘Faculty Focus' series, an interview-style piece where a member of the IANS Faculty shares firsthand insights on a particular infosec topic. In this feature, Ian Amit discusses how shifting the Security/DevOps
paradigm can help improve cloud infrastructure security.
Ian Amit is the Co-Founder and CEO of Gomboc.ai who are providing cloud infrastructure security solutions. Before Gomboc.ai, Ian held senior leadership positions with Rapid7,
Cimpress, Amazon, ZeroFOX, IOActive and has over 25 years of experience in the security industry as a practitioner. Ian is also the co-founder of DC9723 - the Tel Aviv DEFCON group-and serves as a BSides Las Vegas board member. He is also the creator
and co-CEO of The CISO Track - a series of CISO centric curated events.
1. What are some of the issues you’ve seen in cloud infrastructure security between DevOps and security groups?
Ian: Most security practitioners tasked with cloud security recognize how frustrating it is to handle infrastructure issues. We have a lot of tools that enable us to identify typical configuration gaps, and some even provide guidance as far as how each
service should be set up securely. However, in order to change things and secure your particular environment, security works with DevOps who are responsible for the configurations. This means that security doesn’t have the ability (nor should
it have) to change things in production and are at the mercy of the DevOps teams’ bandwidth and knowledge of the particular changes.
DevOps in turn, aren’t just at the service of the security teams, and need to slot in those changes through their sprints and epics. In addition, since the changes only come with a vague reference of the practical change (i.e., a template / blueprint
/ best practice), DevOps is also tasked with figuring out how to implement the intent of the requested change while maintaining the functionality of the applications (as well as the performance, resilience, and other functions that aren’t directly
security related).
Finally – keeping a cloud infrastructure architecture secure means making sure that any changes in the services you are using as well as any new services made available by your cloud provider, are studied, and reflected in your own deployment. This
is similar to the feeling of the ground constantly shifting under your feet while juggling a few flaming swords.
These are the core issues at the current state of cloud infrastructure security – a knowledge gap that keeps expanding as cloud providers deliver exponentially more services each year (and keep updating existing services), inefficiencies in the
remediation process where the entity tasked with finding the problems is separate from the one tasked with fixing them, and finally a friction created by not having actionable solutions which lead to engineering teams having to research what specifically
needs to change in their environment.
2. How do leaders on both sides address these issues and why has it not been working? Can you speak to some of the challenges?
Ian: The current coping mechanisms for security leaders split to two approaches:
- Throwing more human resources at the problem by embedding DevSecOps engineers in the DevOps teams.
- Shelving the issues raised by security detection mechanisms (CSPM, RASP, etc.) and handling them in batches after analyzing the most prominent issues, clustering them to topics, and initiating a lengthy effort through DevOps to address those configuration
issues across the architecture.
This obviously does not scale well or address the problem at its core.
- Adding DevSecOps resources is not scalable and does not solve the knowledge problem nor the responsibility one. It only helps reduce some of the friction that currently exists between security and DevOps to a smaller team spread “closer”
to DevOps.
- The batching approach is slightly more effective; however, it lumps the ongoing issues into large architecture projects that end up consuming more resources, and still only solving parts of the issues as a lot of misconfigurations are de-prioritized
until enough of them gain momentum to make it to the next sprint/epic.
3. What is the solution to shift the paradigm?
Ian: To change the paradigm two shifts needs to happen:
- First is the shift from signature-based detections (whether on CSPM products, or on products that address the security of Infrastructure as Code). Detections based on signatures and rules are ineffective, and perpetuate the knowledge gap, as the
security product providers need to employ skilled researchers to keep track of changes in existing services, and the deployment of new services. This means that coverage will be lacking, and there’s a huge duplication of efforts as each functionality
can be achieved through dozens of different services – each would need its own set of signatures/rules.
- The second shift is moving from template (blueprint/best-practice/etc.) based remediations to tailored ones that take into account each and every unique environment. The current practice of throwing pull-requests with a “remediation”
that is never actually accepted is causing more damage than good. It eats up the trust that DevOps has in security tools and teams and increases the workload of DevOps who need to put in the work to figure out how to change their specific environment.
Instead, we should be seeking pull-requests that would maintain the functionality of the architecture while making surgical changes to close policy gaps in a manner that would be acceptable to DevOps more easily.
4. What are some best practices that leaders could adopt now?
Ian: In the short-term, the best practice I would recommend is:
- Have security engineers take more of a DevSecOps approach - Provide a more effective stopgap to the piling backlog of issues found by cloud security detection products. This would mean investing in the training of those engineers – both to
equip them with the knowledge of the cloud environments and services being used in their environment, as well as with the knowledge of the inner-workings of the applications/architectures they are supporting. That would allow them to address the existing
security gaps with a more practical solution than the existing templates that do not really provide a remediation. In the long-run this approach isn’t scalable and inhibits continued growth – both internally at the application level, as
well as from an adoption of newer (and advanced) cloud services that would require a steep learning curve to fully utilize and secure.
- The best long term, workable approach is to adopt the paradigm shift to move from template based remediations to tailored ones (depicted in question 3). This takes into account every unique environment using automation that isn't dependent on signatures;
remediations become targeted and more successful. This frees DevSecOps to handle higher-level problems.
5. What are the impacts of changing the paradigm?
Ian: The impact of implementing such paradigm change is akin to moving from programming in assembly to doing so at a high-level language. It rids us of the toil of managing the minutia of each configuration option (compounded by the number of services
used) and allows us to work at a higher level of defining what our intents and policies and having an automated mechanism that assures optimal use of services and configurations – freeing us all (security and DevOps) to focus on delivering value
and handling higher-level problems.
About the IANS Faculty
Our Faculty are comprised of over 100 renowned security practitioners with deep, domain-based knowledge who understand - firsthand - the challenges faced by CISOs and their teams.
IANS connects clients with Faculty to help them make better decisions, grow professionally, save time & stay compliant. Get in touch to learn more about how we can help move your security program forward.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.