We should keep it clean in a dirty world.

The last few years of IT Operations has been a wild shift for everyone. In less than a decade, we’ve gone from security a cost center, to compliance and controls as a focal point. We’ve moved from the waterfall development methodology to the speed of CI/CD. For the tech enthusiast and end-user, this is a welcome shift. For the admins, security analysts, and those in charge of just generally keeping the house clean, it has become a footrace back to the basics.

In Cybersecurity, we skipped plenty of steps along the way to our current era. Remember the days of trying to convince our companies we needed basics like IDS, Netflow, access to old logging mechanisms? Gone and replaced at scale with picking massive data lake storage and advanced endpoint agents that monitor and log process and memory activity to the Nth degree. Somehow, we developed such fantastic technology that we forgot how to play fair with the rest of the business, specifically around inventory and asset management.

Advanced persistent marketing lets things get too sexy, too paranoid, and too much of a fake arms race too quickly. We allowed all of this to occur while the rest of the IT world was deploying compute resources, applications, and frameworks at scale. Developers and IT staff having almost limitless ability to spin up resources under company umbrellas for testing, production, and learning. We never mastered asset and inventory management in the early IT days, and we indeed forgot to retrofit and modernize it during the CI/CD shift. Things got deployed, misconfigured, left behind, and often undocumented. Basic security hygiene was often lost the moment resources hit the wire.

Understanding your attack surface and taking control of its hygiene is one of the most straightforward, most cost-effective measures you can control. The ability to continually update your staff and systems on deployments can be part of every development and security process.

So what is hygiene concerning your attack surface?

• A baseline of what assets present themselves to the public (what attackers see)
• Documenting asset knowledge for all operations teams (who owns this asset?)
• Monitoring changes to these assets as they occur (software and service changes)
• Ensuring controls are in place for all assets (is it patched, is there compensating controls?)

A baseline of your assets helps your security team understand what they tasked to defend. The same baseline can help your IT team reconcile the resources with their current CMDB and other resources to ensure consistency.

Documenting asset knowledge helps ensure that baselines, ownership, and relevant asset information is updated. This helps ensure that asset changes to your baseline have owners to answer questions in a timely fashion. Nobody wants to triage ownership while a new service or data storage bucket has come online.

Monitoring changes helps ensure that no new asset or service has spun up without IT and security teams being able to reference against the baseline. Was it expected? What is it exposing? What software and services are new or modified? These are all questions teams should be able to answer against the baseline when there is a change to the attack surface.

Ensuring controls for exposed assets is making controls are in place for things such as vulnerabilities, authentication access controls, and API access. These controls can extend to ensure additional protections such as EDR and logging are active on the asset.

Using these four pillars to create and maintain your attack surface knowledge will give you a leg up on attackers by removing assets in your environment as targets. It will give you a better ROI on tools and analysts by ensuring all assets have coverage. It will provide you with peace of mind that if something activates outside of development or gold standards, people can quickly understand whom to talk to and what needs remediation.

Security is a team sport, and a good playbook begins when everyone understands the playing field.