Reflections from Infosec 2023: The Growing Interest in Asset Management and Discovery

FireMon recently had the privilege of attending the Infosec 2023 conference in London. It was a whirlwind of knowledge sharing, networking, and insightful discussions, with asset discovery and management emerging as some of the hottest topics of the event. Our team was blown away by the number of conversations on the subject, which is why we wanted to share some key takeaways for those who weren’t able to attend.

1. The Rise in Interest of Asset Management:
FireMon’s own Chief Technology Officer, Justin Stouder, spoke on the subject in his presentation: “Effective Security Management Starts with Asset Discovery” (pictured below). In Justin’s own words: “You simply cannot manage what you can’t see, and the enterprise is recognizing this truth. There’s a reason why the cyber asset management TAM is growing 50% year over year. Regarding Infosec, it was thrilling to see this trend develop in person, both in the amount of asset discovery messaging visible when walking the event floor, and the number of people I spoke with who didn’t need to be introduced to the subject and already had a deep understanding of the value it brings.”

2. Mergers & Acquisitions + Asset Discovery = Perfect Fit:
We were approached several times during the event by people whose companies had recently purchased another company, had been purchased themselves, or had recently inherited a new group because of organizational restructuring. We often heard, “Right now, I’m being held do a different standard of accountability and I don’t even have visibility into what I’m accountable for.”

We were happy to take these discussions on, as an asset discovery solution like FireMon’s Asset Manager provides a wide range of insights and support during mergers and acquisitions (M&A) processes ranging from due diligence and risk assessment, to network integration, compliance, cost optimization, and strengthening ongoing security operations. It enhances decision-making, reduces operational complexities, and ensures a smoother transition for the merging entities. 

3. Evolving Threat Landscape:

As the world becomes increasingly interconnected, cyber threats continue to evolve at an alarming rate. It was evident from our discussions at Infosec 2023 that asset management and discovery are no longer mere compliance checkboxes, but integral components of a proactive cybersecurity strategy. Organizations must and are adapting to the changing threat landscape by embracing innovative technologies, fostering a security-first culture, and staying ahead of emerging vulnerabilities.

If you’d like to learn more about FireMon’s Asset Discovery and Management solutions, visit our webpage, request a demo, or view a recording of Justin’s talk on the subject by clicking here.

AWS permission boundaries are confusing. I know they are confusing because they confused me, and it took me a couple years to figure them out. I also know they are confusing because Corey Quinn said so, and asked for someone to make them less confusing.

AWS Copilot, a CLI for the containerized apps, adds IAM permission boundaries and more – Someday someone is going to use very small words and explain to me what IAM Permission Boundaries are. Maybe today?

I’ll probably fail, but here it goes.

TL;DR: Regular IAM policies let you do things, but can also stop you from doing things. Permission boundaries only stop you from doing things. You mostly use them to let someone administer some IAM stuff but not so much IAM stuff that they can escalate privileges (for themselves or someone else). They are a failsafe. If you let someone manage IAM in an account and don’t want them to be able to escalate privileges, you almost always need a permission boundary!

The official AWS documentation has a lot of detail, but is still kind of confusing. This post is to help you understand the concepts and reason they exist, not to know the ins and outs of writing them (with one exception).

Pretend I’m a Fifth Grader, Not a Dummy, and Explain Them Again

Well, if you insist.

Before IAM Permission Boundaries it was REALLY HARD to let someone manage IAM permissions on their stuff, but not create a security problem by assigning too many permissions to something like an EC2 instance or… themselves. It mostly was an issue when you wanted to let them write IAM policies and then assign them. It’s the problem with delegated administration. “Let someone administer some things related to IAM but not those things”.

This is a very common scenario. Developers will often create a role for an instance, lambda function, or container task in their application stack and then assign that role permissions. It could be as simple as letting an instance read data out of an S3 bucket. Turns out, this is tough to handle from a security perspective:

• If you let the developer write their own policies, they could add excessive privileges… like *.*.
• If you let the developer assign policies, they could attach an existing policy with too many permissions.
• If you allow the developer to create a new role AND assign a policy… you have the same issues.

Yes, you could just have security or a high-level admin handle all this, but that is inefficient. Permission boundaries let you have two levels of IAM administrators- the high level ones with overall security responsibility, and lower-level ones that do day to day things.

A permission boundary is just an IAM policy that lists the maximum privileges someone or something can have. You attach that policy and the developers who manage the thing can never give it more permissions than what’s allowed in the boundary. You can then even allow the developer to create new roles and users and assign them permissions, but you require that anything they create has that permission boundary on it. Thus they can never create or change anything and give it more permissions than you want.

I’m Not Sure that was for a Fifth Grader, but Maybe Give Me an Example?

Alice is the super-administrator for an AWS organization. She has to oversee hundreds of accounts, and each account has its own local admins and developers that do the actual Building of Applications.

Bob is one of those local developers. Bob is building a new application and it is more efficient for Bob to create his own roles and policies since he knows what his app needs.

Alice decides to let Bob manage the IAM for parts of his application. Specifically:

• Bob can write and assign new IAM policies with the permissions his instances and lambda functions need.
• There are some other AWS services in use that those components should never touch. Thus you can’t just turn them off with a Service Control Policy. That would break those services for the components allowed to use them.
• Bob is not allowed to assign a new policy to himself.

It’s a classic delegated administration case- Bob is allowed to admin just some of the IAM. This is where you would use a permission boundary:

• Alice creates a permission boundary “A” which allow permissions for the AWS services that Bob’s instances and lambda functions can talk to (e.g. S3, SNS, SQS).
• Alice creates a permission boundary “B” that allows Bob to create IAM roles and policies (and assign them) but NOT assign them to himself.
• Alice gives Bob IAM permissions to create and assign new roles and policies, but any new roles must have the “A” permission boundary. This means those instances and lambda functions will NEVER have more permissions than what is in the boundary, but they can have less.
• Alice assigns the permission boundary “B” to Bob to keep him from assigning permissions to himself. Now he can’t take off the requirement that he has to deploy things with “A” on them.

Yes, there are multiple ways to approach this problem… but the short version is anytime you want to let someone administer some IAM in an account, you probably need a permission boundary if you don’t want them to do too much.

Tell Me Again Why a Service Control Policy Won’t Work Here?

Sometimes an SCP might work, but you can only use an SCP if you are in an Organization and a permission boundary will work in any account. Also, SCPs are really good for things like limiting what API calls you can make (and thus which AWS services you can use), but they aren’t really meant for this kind of granularity and conditionals.

Think of my example above- Alice might have to know the resource identifiers to allow access to services in the account, but not from the resources created by Bob. There are ways of possibly handling this (e.g. resource paths) but it isn’t any simpler than our permission boundary example and doesn’t always work depending on the supported condition keys.

In my Incident Response Training Range I use an SCP to restrict admin users (students) in the accounts from breaking my Organizations-level access and a few other things. But that only works because I allow them full IAM, and they are already one of those super-admins. If I wanted to limit their ability to create resources with excessive permissions, I would need a permission boundary or an SCP to restrict them to only assigning certain pre-made policies.

Can’t I just Use Deny Policies?

Not really. We tried that before permission boundaries existed and, aside from the complexity, there were just too many loopholes.

Can I Have One More Simple Example?

Sure thing! Here is one we use ourselves.

Some users let us make IAM changes in their accounts. We use a cross-account roles for this. When users deploy the role, they apply a permission boundary that never lets us change permissions on ourselves. This prevents privilege escalation.

I Think I Get It, But How Do All These IAM Policies Interact?

Check out the AWS documentation for their policy logic evaluation, but here are my crib notes:

• Service Control Policies limit what anyone is allowed to do in an account (e.g. they can turn services on and off).
• IAM permission policies allow users and roles to do things in an account.
• IAM resource policies allow users and roles to interact with the resource the policy is attached to.
• Permission boundaries set the maximum privileges a user or role can have. They don’t allow you do to things, but they can stop you from doing things.

The policies all work together. For you to do something, you have to have a permission someplace in the stack to do it, and have no deny policies anywhere from stopping you from doing it. Any single Deny will override any Allow, no matter where it is.

Remind Me Again When to Use Permission Boundaries?

When you want to allow someone to administer some of the IAM in an account, but still limit how much, you should find yourself thinking of a permission boundary.

Even when you are using advanced IAM tools like our new FireMon Authorization Control, you may still want some permission boundaries, especially in highly-sensitive accounts.

What’s the One Example You Said you Would Include?

Although permission boundaries are meant to prevent you from doing things, they still need you to specify all the allow permissions. In other words, if you write a permission boundary with a DENY statement to block the one thing you don’t want that user/role to do, you would still need an ALLOW * statement or they can’t do anything.

This is the part that confused me at first, since I misread Amazon’s description and thought you could just use a permission boundary to block actions. You can, but except for a resource policy use case I don’t want to get into today, the permission boundary also needs to include everything you want to allow. You can’t just DENY one thing in the permission boundary and ALLOW other things in the regular IAM permission policy and have it work. The permission boundary also needs to have the ALLOW statements (and yes, I cheat and will use ALLOW * here at times).

I’m Still Confused

Drop me an email. Seriously, these things are legit confusing.

RSA 2022 is almost here! I’m excited to see many of you face-to-face in just a few weeks in San Francisco. So much has changed at FireMon since RSAC in 2020, yet our core mission of protecting our customers is still true north. If you are attending RSA, I’d love to see you and catch up.
It’s been a few years since we all gathered for RSA, so I thought I would dust off my list of Top 5 Tips for a great RSA Conference.

1. Shoes – At 20,000+ steps a day, shoes matter. Make sure yours are comfortable.
2. Hydrate – The days and nights can be long. Water is your friend.
3. Refresh – San Francisco is a great city to get out and walk around. I like doing this in the mornings. Take your workout outside.
4. Friends – This is a great opportunity to reconnect and help others in the industry.
5. Calendar Link – Make it easy for others, and you, to book time.

Cyber security continues to accelerate at a record-breaking pace with work from anywhere, the great job reshuffle, and increasing cloud adoption acting as fuel. FireMon acquired DisruptOps last year to jump ahead in cloud security operations, and Jody Brazil, FireMon’s founder, returned as CEO. I also came over with the acquisition as COO focusing on all things customer, and have been continually impressed with FireMon’s people, technology, and innovations.

FireMon has been busy these past few years enabling our customers to improve security outcomes by improving security operations. FireMon is the market-leading provider of security policy management solutions to reduce risk, manage change, and enforce compliance. As the role of security engineers continues to evolve, we have delivered new solutions for a pragmatic approach to zero trust, cloud security operations, and more. Come see why over 1,700 of the companies continue to trust FireMon.

FireMon is hosting two great events this year. First, FireMon’s long-running VIP Press Club event is back on Monday night, with great wine and food, and even better networking. Maybe even a surprise guest (Have you seen who has joined our team recently?). Reach out if you want an invite before they fill up. Next up is our RSA customer event at Wine Down on Tuesday. Sensing a theme here? If you are or want to be a FireMon customer, reach out for an invite and come meet the FireMon team over a glass of wine.

It’s almost time for RSAC 2022. Travel safely and I hope to see you there!

– Matt Eberhart
https://www.linkedin.com/in/matteberhart/

It’s been seven months since DisruptOps joined FireMon with a mission to improve security outcomes by improving security operations. I’m excited to announce that DisruptOp co-founder Rich Mogull is joining us as SVP Cloud Security to continue pioneering the future of cloud security operations. Rich’s experience living in the future of security operations and seeing firsthand how strategies and tactics from the SRE and DevOps movements deliver both effectiveness and efficiency across a new model of distributed security operations, will be key to the future successful outcomes FireMon’s customers achieve. I sat down with Rich as he prepared for day one.

<Matt Eberhart, COO @ FireMon> Rich, welcome to team FireMon as SVP Cloud Security. Tell me a little bit about your decision to join full-time after being a long time advisor, and originally a founder, of DisruptOps.

<Rich Mogull, SVP Cloud Security @ FireMon> Am I allowed to say FOMO? It really came down to seeing the opportunities in front of us and wanting to be more involved than I ever could as an advisor. We spent years building DisruptOps from a hacked-together demo I did last minute at Black Hat into a full-featured cloud security operations product. Rather than being an end, the FireMon acquisition just added more fuel to the fire.

I see a massive opportunity to improve how we run security operations, especially in the cloud, and it wasn’t one I wanted to watch from the sidelines. Moving into this role not only allows me to continue executing on our vision for DisruptOps, but now we get to play in an expanded arena thanks to the rest of the FireMon product line. For example, DisruptOps really worked best in pure-cloud scenarios, but now we get to extend into hybrid and zero trust environments. Plus we gained some huge cloud network security capabilities, which is one of the toughest areas to manage even if you start with a blank slate.

There are some very cool things in the works at FireMon and joining full time allows me to help influence the solutions we build in a way I never could as an advisor. And it allows me to give the community something more than just words and slides.

<Matt> You’ve worn a lot of hats in your security career and have a long history of sharing your opinions. You were a big part of my journey to cloud security. What trends are you excited about and how does that play into your new role at FireMon?

<Rich> When I first started in cloud security over a decade ago I was part of a very small group being told that no real company would ever move into the cloud. Now everyone and everything is moving to the cloud, in many cases faster than enterprise IT and security teams can support.

The most exciting trend is that organizations are adopting cloud native ways of doing things. Yes, it’s still early and there are plenty of places still carrying across their old security practices, but there are a lot more people that understand how cloud is different and takes its own approach. I will also add DevOps to the mix, just to create a little more chaos.

We are in the early phases of a generational shift in how we approach and execute security operations. Everything is becoming more distributed, event-driven, and automated.

Aside from the generally increasing usage and importance of cloud, there are a few trends right now I find really interesting and fun. For the past year or two, I’ve been spending a lot of time on cloud incident response and that has influenced the advice I’ve been feeding back to the product team. There are some really cool things you can do in the cloud that are much harder on-premise thanks to the ubiquitous nature of APIs in the cloud.

Identity and access management is also really heating up, thanks to just-in-time capabilities converging with attribute based access controls. 20 years ago I wrote up a concept of “dynamic authorization” in a long-dead Gartner research report and we now have the capabilities to achieve risk-based authentication and authorization at scale. It’s a game changer, and just in time since we are putting all of our administrative interfaces on the Internet and letting admins access them from personally owned devices on untrusted networks.

The last trend isn’t new to us, but is just starting to get real traction. At DisruptOps we built our product early on for what people now call ClickOps. Just to be annoying I’ll call it ClickSec, and I love the idea of pushing security notifications with one-click remediations into the hands of those who own an application or environment. Let’s bust some silos.

<Matt> I’ve always been fascinated by your longtime passion for being a first responder. How does that shape your views of security and the way you look at the world?

<Rich> Heh…anyone who follows me on Twitter knows I can’t shut up about my emergency services work. I was a lifeguard at 16, an EMT at 19, and a paramedic by 22. These days I mostly focus on disaster response but I’ve worked fire, ski patrol, mountain rescue, and other odd jobs. Those were some of my most formative years and that work is really foundational to who I am and how I view things.

Working as a medic colors you with a certain approach to decision making. We are taught to assess incredibly chaotic situations in very little time, frequently in austere or even hostile environments. Paramedics are the masters of answering “sick or not sick” and developing a plan of action without a fraction of the diagnostic tooling other medical clinicians have available. In security, especially in incident response, we are often in the same position of making critical decisions without access to complete information, and we need to constantly revisit our decisions for changing circumstances.

Taking a step back there are the larger perspectives around risk and people. Human behavior governs everything, and we can’t assume we can slather on some technology fix to a systemic or behavioral problem. Our technologies need to account for human behavior, and not assume it will change. It’s like the patient having the heart attack that doesn’t want to go to the hospital–do I spend an hour arguing with them? Or do I just tell their spouse they’ll need the number of a good funeral home before bedtime? One of those is a lot more effective at getting the person into the back of my ambulance.

<Matt> I know the answer to this question, and I’m glad I’m not close enough for you to take a swing at me, but…Star Trek or Star Wars? And why?

<Rich> Oh heck, I like them both, but both are kind of hit or miss with the new stuff. I’ve been a bit disappointed by Discovery and Picard. Heck, The Orville is doing Trek better than Trek right now. The latest Star Wars films weren’t all what I hoped, but they are nailing it with most of the TV shows. I’m especially looking forward to Ahsoka since I consider Rebels to be probably my favorite Star Wars property not counting the original films.
But if I have to choose, Star Wars. It’s a bigger canvas that plays with fantasy and archetypes, whereas Trek is more a treatise on humanity and optimism. I think I’ve become too cynical in my old age to put Trek in the lead.

<Matt> FireMon and DisruptOps both have a focus on security hygiene. I’ve heard you say – in security, it isn’t just knowing what to do, but often the ability to do the right thing at the right time that makes all the difference. What should security hygiene look like in the future?

<Rich> How long do you want this post to be? Alright… I’ll try to keep it short(ish).

As I mentioned a bit earlier, for most of the history of security we have relied on silos. Well, not just security, that’s how we handled pretty much all IT operations. The silos weren’t created randomly; they are the natural outcome of how we had to build and manage our technology. In a datacenter someone had to own and run the network, someone else the servers, someone else the security. Physical architectures create chokepoints because it isn’t like we can let everyone run around and plug in their own wires. IT was defined by scarcity.

Cloud blew a lot of that apart. Anyone with a big enough credit card has access to thousands of custom networks and servers they can build with a few API calls. The choke-points disappear, everyone is an admin, and now we are all catching up to figure out the best ways to still manage risk.

The future of security hygiene is retooling operations to account for the more distributed nature of IT operations themselves. To me, the ideal is that security defines the “rules” for managing risks, which are then codified into policies, infrastructure as code templates, and other tools for detective, preventative, and reactive controls. Then the individual teams manage their day-to-day issues, with security keeping an eye on things and stepping in to manage the big incidents.

We use automation to identify issues and deviations in near real-time, and then, when possible, route the issue and a recommended fix (or automation button) right to the team that owns that environment. At the same time, it shows up on security’s list of open issues for tracking and validation. As great as preventative guardrails are, they can’t account for everything so we need the right mix of controls to reduce friction and enable high velocities while still managing risk.

Security hygiene is a mix of secure baseline templates, configuration, threat, and event monitoring, preventative guardrails (when we can), and finding and routing issues and remediations to someone empowered to take action right then and there. Everything is much more collaborative and real time. Right now, a lot of this looks like IaC/DevOps for a good start, and ClickOps for keeping things there, but we are really only at the earliest stages.

<Matt> Thanks for sharing your thoughts Rich. Welcome to FireMon! Right now, RSA 2022 is in person. Rich and I are both attending and hope to see you there.

One of the most critical aspects of proper security hygiene is keeping critical security devices patched and up-to-date. Firewalls and network security devices running outdated OSes is a top source of unintended breach avenues waiting to be exploited.

A current example of this came from Cisco Firepower devices: Cisco recently released a field notice alerting users that several OS versions powering these devices may stop receiving security intelligence updates in March due to an SSL certificate change.

On an enterprise network, manually searching for devices running the affected OS versions would be a time-consuming nightmare. Luckily, security operations teams have help in the form of FireMon’s Security Intelligence Query Language (SIQL). Shortly after Cisco’s field notice, FireMon released to their clients a list of the impacted OS versions, a SIQL query to find devices running those versions, and instructions to apply the fix. FireMon clients contact your CSM today to get the fix immediately.

This isn’t something you’d ever hear about on the evening news or even a quarterly review of business practices. But it is the sort of thing that security operations teams do on a daily basis that prevents cybersecurity disasters from happening—and keeps them from making news in the first place. With this simple but powerful fix, FireMon’s clients are able to locate and update the devices running affected versions of the OS and ensure their devices continue to receive critical security intelligence updates.

FireMon’s real-time security policy management platform is built for the enterprise, with speed and scalability the competition can’t match. And the power and flexibility of SIQL, our built-in query language, gives FireMon customers the ability to instantly and easily find information about their network. As one customer put it, “FireMon SIQL enables us to build analytics to use our data to gain superior insights quickly. Competitors are like ‘find’ in MS Word where FireMon is like Google.”

To improve security outcomes, you need to improve security operations. FireMon has been doing that for our clients for over twenty years. And if you’re a Firepower customer, don’t wait: the SSL changes will take place on March 5, so contact your CSM and double-check that your Firepower devices are running unaffected release versions today.

Cloud security in your workflow. Not in your way.

As we announced today, DisruptOps is now a part of the FireMon family of products.

Perhaps the most exciting part of this acquisition is the opportunity to introduce DisruptOps to those who may not know us.

Tl, dr:

Whether you’re born in the cloud or migrating workloads from on premises data centers, if you’re building and running software on public cloud infrastructure and looking to improve security operations, there’s a good chance we can help.

• DisruptOps is a cloud security operations platform that brings security and DevOps teams together to find, understand and fix security issues across their public cloud infrastructure.
• Security & DevOps teams look to us when they want a solution to:
  • Understand their cloud security risk
  • Get critical issues routed to the right responders
  • Bring cloud security into a DevOps workflow, and
  • Reduce their Mean Time to Respond (MTTR)
• DisruptOps supports AWS and Azure infrastructure services (GCP support is coming soon).
• Use cases: Distributed Alerting & Response, Cloud Security Posture Monitoring, Real-time Threat Monitoring, Automated Guardrails
• Want to learn more? Visit the DisruptOps product page.

Let’s dig a little deeper…

The way we build software has changed for good. On-demand, self-service access to infrastructure and the use of a DevOps approach has changed expectations about how fast we can deliver new features and whole software products. Getting products into the hands of users faster is the good news. It’s the resulting speed, scale, and complexity that become a challenge for security teams. Security operations must evolve to address this new reality.

Building & running apps in the cloud creates new risks for security to consider

A defining feature of cloud is the control plane – the console, CLI and APIs represent a unified admin console for everything and it’s accessible over the internet – we need to address configuration risk, operational risk, and respond to real-time indicators of threat.

In many cases, DevOps shifts operations from a centralized function to a distributed function that’s embedded in smaller, cross-functional teams. Security teams often no longer have the access or entitlements to the infrastructure to apply controls and remediate issues. In this model, the path to applying security controls, at least partially, runs through the DevOps team.

A DevOps approach leads to extreme automation and speed – the long project lifecycles and governance pipeline we used to rely on in security are contracting. Everything is moving at machine speed and scale.

Every business is becoming a software business and security expertise is needed now, more than ever. But security must evolve. Otherwise security will become a roadblock for the business, or development teams will simply work around cumbersome processes and increase corporate risk.

We’ve built DisruptOps to bring Security and DevOps teams together to improve security outcomes.

How we can help

DisruptOps connects to your public cloud accounts and immediately builds an inventory of your resources. We capture changes and update that inventory in real time, so you always have visibility across your cloud infrastructure.

Continuous monitoring using hundreds of posture checks based upon the CIS Benchmarks and AWS Best Practices help find misconfigured resources.

Built-in, event-driven threat detectors identify risky events, like root user logins, changes to user or group policies, or modified bucket privileges.

We also integrate with and ingest events from cloud provider services like AWS Security Hub and GuardDuty, and third-party cloud security posture management tools.  If you have other detective controls running, we’re eager to expand our integrations and enable you to “bring your own issue” and leverage the DisruptOps platform to engage the right responders and accelerate the remediation process.

All of these sources are used to identify security issues and enable you to apply cloud security best practices. While visibility into your risk is good, getting issues fixed is what really matters most, and that’s where DisruptOps really shines.

Finding Issues

Unlike most tools that emphasize security assessment and alerting, DisruptOps is a powerful platform for real-time response.

Our Issue Feed is designed to surface the risks that matter most and enable users to investigate, understand, decide, and act.

The feed is filtered to display critical and high severity issues in your production environment by default. Granular filtering using a variety of attributes enables you to drill down into specific areas of interest.

The feed is refreshed and updated as new issues are found.

Getting Issues to the Right Responders

Running security assessments, generating a long list of issues and throwing it over the transom to the Ops team to fix is not a recipe for success. DisruptOps aligns your projects, accounts, and teams to enable you to get the right issues to the right responders inside the tools they already use like Slack, Microsoft Teams, and Jira.

The result is less time lost to chasing down the right responder and more time for improving your cloud security operations outcomes.

Each alert includes links to the event and playbook that generated the issue and the issue itself, along with additional context about where the issue exists. Users can click through to the DisruptOps console to investigate further or choose to apply a pre-built response option from the alert if the playbook is configured to include them.

Understanding Issues

Expanding the Overview section displays issue content written by our security research team and designed to help a responder understand the risk and offer recommendations on how to respond. Links to external documentation from the cloud service provider are included for most issues to save time for a responder who wants to research further.

Fixing Issues

DisruptOps provides multiple options to enable responders to choose their preferred response path.

Expanding the Manual Remediation section displays multiple remediation options. Depending upon the issue type, options include code snippets that can be copied and dropped into Terraform and AWS CloudFormation templates, the CLI or SDKs where available. We also include instructions to implement a change to the runtime environment using the cloud provider console.

DisruptOps also includes hundreds of pre-built, automated response options. Administrators can choose whether or not to include them when configuring playbooks for specific issue types. When included, they enable responders to apply an automated change to the affected resource with a single-click from within an alert, or from the DisruptOps console. While automated response is not appropriate for every issue, it is very handy for repetitive, labor-intensive remediations or for a few issue types that represent critical risk you never want to see in your environment.

Interested in learning more?

We’d love the opportunity to see if we can help improve your cloud security operations. You can learn more about the DisruptOps product or book a brief demo.

The year that changed everything, and how you’ll have to adapt in 2021

The pandemic will burn itself out eventually, but its effects will not. We’re different people now – we’re intimate with streaming catalogs and we’ve learned to knit, yodel, or speak Esperanto.

And the way we do business is forever changed as well. We’ve learned that innovation is more than a boardroom buzzword and it’s more than something we’ll do in the undefined future. It’s here now, we’re actually doing it, and it’s becoming engrained in our business processes. Iteration isn’t just for software developers anymore.

The challenges and opportunities of the post-pandemic world are going to look very different than those of 2020. How can IT leaders prepare? Where should they be investing?  How will their careers be impacted? FireMon CEO Satin Mirchandani joined other technology business leaders on a panel led by eWeek to discuss these topics and others in a free-wheeling conversation.

What We Did Right

“COVID caught us all by surprise,” said Mirchandani. But he also said that organizations rose to the occasion and did some pretty remarkable things. “Candidly, we were pleasantly surprised by how quickly our customers moved to work-from-home status. Most of our customers effectively shifted within weeks of making the decision, which is extraordinary. Now, 80 to 90 percent of our clients’ employees are working from home.” But Mirchandani also noted that the move wasn’t as automated as many of them would have liked. “There are lessons there for the future. COVID has highlighted the need for automation across all industries and business siloes.”

While work-from-home grabs headlines, the panelists focused more on how COVID has changed the way business leaders think about innovation. Vijay Kurkal, CEO of Resolve Systems, said, “When the pandemic first hit, I figured a lot of IT leaders would be extremely busy fighting fires and figuring out how to respond to the pandemic. But the real surprise was how quickly IT leaders not only adjusted, but also recognized the situation as an opportunity to accelerate innovation.”

Kurkal reports that the number of conversations his company is having about how to use automation to support innovation has more than doubled over the same time last year. “IT leaders are increasingly realizing that they need to respond to the speed of change. They are not holding back on innovation, and that’s fantastic.”

Cost Takeout vs. Faster Innovation: Dueling Priorities

So now the challenge is to understand how we can iterate innovation better, faster, and more cost-effectively. Because the pressure won’t be off when the pandemic is over — in fact, it will be more intense for several reasons.

First, business leaders have seen how rapidly IT can pivot, so now they’re going to expect that same level of agility all the time – as they should. Second, they’re going to want to do that without increasing budgets. According to Emmet Keeffe, Operating Partner at venture capital and private equity firm Insight Partners, periods of innovation are typically followed by periods of cost-takeout, where businesses redesign their fundamental components to the lowest-cost structure that can support their objectives. So IT, security, and compliance will be expected to continue innovating at the pandemic pace with no additional resources.

Mirchandani was frank about the impact of these opposing priorities. “Maintaining momentum is going to be hard. The to-do lists are blank and the technical debt has been paid. The excitement is over and now we’re facing the need to meet priorities while cutting costs. It’s going to be a real challenge in 2021 and beyond.”

Everyone Is a Software Developer Now

The era of shelfware is over. As COVID has put immense economic pressure on enterprises, they’ve realized they’ve been buying a lot of tools, deploying them relatively sparsely, and getting only a few cases of value out of them.

“That’s changing completely,” Mirchandani said. He reports seeing a tremendous focus on making sure everything purchased is used fully and that its maintenance is on point. “If, for some reason, software isn’t deployable or no longer matches the business use case, it’s out the door,” Mirchandani continued. “And businesses want to eke out every additional use case possible from the software they keep.”

IT leaders are finding creative ways to achieve their businesses’ objectives without adding costs. For instance, Sam Gilliland, CEO of Cherwell Software, mentioned a large financial services company that requires its teams to determine whether their project can be achieved with automated workflows or no-code before they source any new software.

There’s a lot of power in giving business analysts, product owners, compliance officers, and others the ability to interact directly with automated workflows. When business rules can be written in plain English and implemented through drag-and-drop or other simple web interfaces, and when changes can be made with a few clicks, the need to constantly purchase and deploy more costly software or sign more onerous licensing agreements is reduced to the bare minimum and the speed to market shrinks from months to weeks or even days.

This shift to automation, low/no-code, and intent-based everything is going to drastically change the post-pandemic IT organization. Of course, the use of these technologies requires a different way of thinking, so new types of IT leaders will emerge as well.

The Ascension of the IT Leader

There are new rules to the game, and business leaders are asking about them. “It’s incredibly clear that technology is driving competitive advantage and differentiation for businesses,” said Kurkal. “This is a huge window of opportunity.”

Historically, IT leaders have believed they should sit alongside business leaders when strategic decisions are made. After all, businesses are only as good as their technology enables them to be, so the insights of IT leaders can help those decisions yield the best outcomes. Thanks to COVID, other executives are recognizing how integral IT is to their own teams’ successes. And when every business analyst or compliance officer is writing their own rules and workflows, they understand the value of IT in a very personal way.

The new IT leader will possess the ability to manage the competing priorities of cutting costs and speeding innovation while motivating the workforce to drive business outcomes across the organization. “That’s no small task,” said Gilliland, but it’s one CIOs are well-prepared to address.

Mobilize Your Organization to Embrace Automation at Scale

All the panelists agreed that automation will be front and center in upcoming years. The history of automation is a long one so this isn’t a new topic, but what is different is how automation is being implemented. In the past, an engineer would write a PowerShell script to perform a repetitive task. These one-off scripts made one person’s job easier, but they didn’t address inefficiencies in the organization as a whole. Next, automation evolved into a bolt-on that solved a singular need in one area of the enterprise. By now, most enterprises have a dozen or two automated tools that help a department or a process but are treated as tactical aids, not strategic solutions.

And nobody knows if all those tools are worth buying and maintaining. Kurkal said that when he asks CIOs and IT leaders to quantify the gains in productivity or cost savings their bolt-on automation tools have delivered, they don’t have good answers. This is what happens when tools are purchased outside of a strategic framework. “It’s not about automating individual tasks. It’s about orchestrating a service.”

The alignment of automation and business objectives is where the power of automation really shines, enabling faster delivery of services, faster responses to changing business needs, and faster responses to incidents. And business leaders are recognizing the need to strategize automation. “Conversations around automation are shifting away from siloed point tools to more of an integrated automation center of excellence. So IT leaders should be thinking in totality about how they can deliver an integrated service to the business.” That’s the next level of maturity enterprises need to be working toward.

When asked about the customer journey on the road to automation, Mirchandani said that most FireMon customers’ journeys look very similar. “They start with visibility. Then they move into compliance and governance. And finally, they move into automation.”

The Two Trends that Are Changing Cybersecurity

Mirchandani summarized the two biggest trends in cybersecurity succinctly: “DevOps and the dissolving perimeter.” As the traditional perimeter dissolves and moves towards applications and end points, the challenge for security is how to meet that need while remaining usable. Enterprises need to deploy SASE applications without giving up the granularity of compliance and governance that they’re accustomed to enjoying from a network security perspective.

Mirchandani says that the rush towards SASE, SD-WAN, and software-defined everything is incredibly powerful. “These technologies enable security teams to keep up with their business’s need for speed and agility while providing the appropriate level of security.”

Another trend driving the evolution of security is the adoption of a “shift left” approach to DevOps and CI/CD pipelines, meaning that software testing is incorporated earlier in the software lifecycle. “FireMon customers are pushing incredibly hard to enable their own customers to use these CI/CD pipelines.” The challenge for them is how to translate security into code and deploy it. “This need is driving FireMon toward headless API architectures,” said Mirchandani, “so we can become part of an enterprise-wide DevOps initiative or an automation initiative and still be used in a way that’s consistent with these newer emerging philosophies.”

Now That All Enterprises are Agile, Security Automation is Not Optional

Digital change was already happening when COVID hit: now, it has happened. CEOs are saying their enterprises have gotten more done in the past six months than they had in the previous six years – and all the panelists agreed that this pace of change is here to stay.

The panel audience identified automation and virtual collaboration as the two most important initiatives in their enterprises today. Cybersecurity weighed in at 33 percent, which all the panelists agreed should be higher. “We think the share of dollars allocated to cybersecurity needs to climb,” said Mirchandani, but he also noted a mitigating factor: “There just isn’t enough talent out there to implement security well. Enterprises need to be aggressive in implementing security automation so they can secure their data and workflows, no matter where they reside.”

As enterprises move to hybrid-cloud networks, they need more visibility than ever. But, despite the compelling business case of cloud-first technologies like Secure Access Service Edge (SASE), technology leaders often worry about maintaining visibility and control across an increasingly complex hybrid network.

Through its new partnership with Zscaler, FireMon has responded to this need by enabling our customers to visualize and manage Zscaler Advanced Cloud Firewall policies alongside those in traditional network security enforcement points like firewalls, routers, and cloud security groups. This simplifies enterprise adoption of SASE and supports real-time policy analysis that enables security and compliance.

Businesses that combine FireMon and Zscaler can visualize configuration, policy, and rule usage statistics across all network security enforcement points through a single pane of glass.  They can validate policies across regulatory and corporate standards, analyze access across the network, and monitor for change to identify risks quickly. Security is improved and governance is easier with automated reporting through a single pane of glass. And for organizations that haven’t yet made the move to a hybrid-cloud network, pairing FireMon with Zscaler eases the pain of migration.

The end result is less complexity, better security, and a faster move toward zero trust, cloud-centric network and security architectures.

Easily Manage Your Zscaler Policies (and everything else)

Joint customers of FireMon and Zscaler can easily manage policies, ensure compliance, and monitor changes across Zscaler Advanced Cloud Firewall and traditional firewalls, as well as other network security enforcement points.

On a practical level, integrating FireMon and Zscaler makes daily security operations easier in many ways. For instance, users can:

• Confirm all firewalls, including Zscaler, and consistently enforce network security policies
• Visualize the Zscaler Cloud Firewall as part of the hybrid network map
• Ensure Zscaler rules are created according to enterprise best practices and identify overly permissive rules
• Analyze network paths containing Zscaler Cloud Firewalls to ensure proper connectivity and segmentation
• Audit Zscaler policies as part of the overall audit process
• Identify configuration and rule changes, as well as access violations, across the hybrid network
• Implement consistent security for all branches.

These use cases are enables through rich API integration between FireMon and Zscaler.   Using the Zscaler API, FireMon collects information from passes it to FireMon’s Agile Network Security Policy Management platform and FireMon’s Automation. Zscaler data is aggregated and used to build the FireMon network model, which includes networking, security controls, and assets. The Zscaler Cloud Firewall can be visualized as part of the overall network map.

FireMon and Zscaler: Integration in Action

The FireMon platform uses Zscaler policy information to apply real-time policy analysis, so the right security policy enforcement is always in place and proper network segmentation is always supported.

Joint customers of FireMon and Zscaler are able to visualize configurations, policies, and rules across all network security enforcement points through a single pane of glass

FireMon and Zscaler – A Powerful Pairing

Policy Management
Normalize and manage policies across firewalls, next-generation firewalls, and cloud environments from different vendors through a single pane of glass.

Policy Validation
Validate policies against regulatory requirements or custom-defined policies.

Access Analysis
Confirm Zscaler security controls enforce the desired enterprise-wide access, security, and compliance policies.

Rule Base Compliance
Monitor and ensure security controls continuously maintain compliance with defined access and rule policies. Identify rule, access, and configuration compliance violations.

Network Mapping
Automatically collect and build Zscaler Cloud Firewall data into a visual and interactive model that provides end-to-end network abstraction of access paths with access path analysis and network map visualization.

Rule Review
Analyze firewall configurations to identify hidden, unused, shadowed, or overly permissive rules that provide more access than necessary.

Change Tracking
Track changes to Zscaler Cloud Firewall rules for compliance or rule review analysis. Ensure changes are certified. Identify when a change occurred, who made the change, whether it was expected, and if the change created a negative impact.

You Can’t Stop Complexity. But You Can Control It.

Cloud-first is permeating the world of enterprise computing at a rapid rate, but it can lead to policy sprawl and poor visibility. Organizations need to choose technology stacks that can be easily integrated and automatically orchestrated if they’re going to realize the benefits that drove them to the cloud in the first place – flexibility, agility, scalability, and speed to market.

Organizations that implement FireMon and Zscaler Advanced Cloud Firewall can enforce consistent security and compliance policy across heterogeneous hybrid-cloud networks that span data centers, the cloud, and SASE architectures. Hybrid-cloud networks are more secure and their governance and compliance efforts are greatly simplified because management is centralized through a single console that displays normalized data and visual maps.

Schedule a demo today to learn more about how the FireMon and Zscaler integration helps you close the complexity gap, or register for free for Zenith Live 2020, Zscaler’s Annual Cloud Summit and attend our presentation on demand.

Network security professionals are unsung heroes. Everyday news app visitors won’t read about all the wonderful work you’re doing. On occasion, they’ll only see and read about fellow professionals having the worst days of their lives. But while the headlines stay away, FireMon sees you as you continue to make the world go round…securely. Which is why this Thanksgiving we are thankful you are:

• Protecting our identities from online fraud and making sure that we don’t just click on that link selling a $1 television on Black Friday.
• Ensuring the safety of physical equipment so that we can use an ATM or a gas pump safely without incident and without feeling like we have been hit by the Attack of the Clones.
• Securing utilities so we can flip a switch and the lights come on and getting our own bills, as opposed to paying for the neighborhood.
• Keeping the GPS in our cars in check so that we don’t pop in Ohio and land up in Florida.
• Securing our mobile devices so grandma can keep playing Candy Crush and we can access our work and personal apps in the same place.
• Holding the hands of shippers as you help them deliver packages safely and letting us make last minute delivery changes securely on online portals.
• Keeping a check on our medical information so that we don’t end up finding that we have been cloned and our data is all over the dark web.
• Helping businesses secure the data of their customers, staff, and consumers, while avoiding costly leaks that can put our favorite sneaker store out of business.

The list of the daily challenges you face is endless and so is your tireless work. No wonder on occasion you feel like the little boy with his finger in the dyke – keeping a literal sea of threats at bay by plugging a single hole. From all of us at FireMon, we salute you! We know the sheer volume of security threats you keep at bay each day, so this Thanksgiving… The FireMon Family is thankful for you!

In the age of clouds and hybrid clouds and multi clouds, effectively managing network and firewall policy and compliance isn’t a simple matter for any organization.

That’s especially true for a leading provider of enterprise-level SAAS solutions with more than 150,000 customers around the globe. Moving fast to meet business needs and respond to changes is non-negotiable. Security must be agile to protect the global network and to ensure compliance.

This global SaaS provider turned to FireMon to meet three key challenges:

• Lack of clear visibility into security risks and compliance within their existing network policy processes. They had four different sources of “truth” to support their security policy workflows. This limited the effectiveness of their existing security automation processes and made it difficult to ensure compliance and to predict the impacts of rule changes before implementation
• Support for their digital transformation initiative. The company is migrating on-premise services to a multi-vendor hybrid cloud model to improve data portability and scalability. To support this migration, security needed to normalize policies across environments. Otherwise any attempts to automate processes and ensure compliance would be difficult, resource-intensive, and error prone.
• The need to accelerate application availability. Given the company’s large, global customer base, application updates are delivered continuously. Processes must be fast and automated, including appropriate security and compliance checks.

FireMon earned their business by addressing these challenges. We provided an agile security platform that fully supports the company’s existing automation processes within their complex environment, thanks to these core capabilities:

• Interoperability: Our Open RESTful API framework allows their team to mine and manage policy and ACL settings on devices throughout their entire environment, both as it now exists and through its planned transformation. Our solutions provide intelligence and visibility to ensure continuous compliance while supporting their analytical and reporting needs.
• Scalability: Our solutions meet their requirements to provide a single source of policy “truth” for more than 900 firewalls and routers managed by complex policies and ACLs, and will continue to meet security and compliance requirements across the company’s on-prem and multicloud environments as they add new applications and services at an increasing rate.

Their IT team will now be able to automate the processes of evaluating security risks and monitoring policy compliance, and verify that the configuration changes that actually occur match the ones that were planned. As a result they can automate with confidence.

The complete solution incorporates our integrated capabilities in Network Security Automation, Continuous Compliance and Risk Mitigation, all optimized to work effectively within their complex environment.

Do you face tough challenges in ensuring security and compliance while increasing your agility across a complex, evolving hybrid network?  FireMon is the only agile network security policy platform giving you everything you need to streamline firewall and cloud security group policy.

Request a demo to see how FireMon can help your organization.