As a security executive, you have a curious gig. On one hand, you’re responsible for securing your organization across multiple systems, networks, clouds, and geographies. On the other, your team owns none of those things.
Organizing resources in a way that makes visibility possible beyond the data center (assuming you have that to begin with) is hard. That’s because the way you achieve visibility in the cloud, or at the edge, is fundamentally different than it is in the data center.
How securing the cloud is different
Higher-altitude access – In your data center, you have direct access to your switches and firewalls. You can look at things like netflows, and see based on IP addresses which network devices connect to one another.
In the cloud, Amazon (or Google, or Microsoft) take care of that low-level network machinery for you. You can’t just access network telemetry ‘hot-off-the-press’ the same way. To get the same signal, which in this case is a list of devices connecting to one another, you need to go through your cloud provider’s offerings list. In AWS, for example, it’s Cloudwatch.
Reduced context in IP address information – In the data center, network devices often hold onto an IP address for a long time. This makes correlating device activity more straightforward than in the cloud.
In the cloud, compute can often be ephemeral in nature. The same IP address can represent multiple different devices in the span of, say, an hour. Also, serverless compute in the cloud (think: Amazon’s Lambda service) means some of your cloud activity never gets a traditional IP address in the first place. In this environment, device context that is based on IP address information is an unreliable identifier. All of a sudden, you need more data points (like instance IDs) to keep track of entities in the network.
Inverted philosophy on connection and visibility – In the data center, everything connects to everything by default. You set up firewalls and policies to stop connections you don’t want happening. In the cloud, where compute is segmented by default, you need to specifically enable particular connections to happen. This enablement is best done via roles and policies, as opposed to IP addresses, ports, and protocols.
Why you need to be proactive about cloud visibility
If you know how to use it, the cloud provides you the opportunity to establish repeatable and automated processes that meet your organization’s governance requirements, by design. While the cloud has a reputation for being dangerously untamed, order can be established rapidly with the right approach.
The cloud also provides the ability to automate controls that are critical for meeting compliance requirements. Between customers, geographies, and verticals, compliance requirements can be a wee bit complex, but with proper resource tagging, the process of logging, alerting, and reporting can become a great deal less complex than on premise environments.
How to start achieving visibility in the cloud
Applications and services in the cloud are accessed by numerous users in your organization. Connections and data flows are maintained between these domains. It is critical to establish a security architecture that meets the requirements of each domain and their interdependencies.
To achieve this, your often-disparate teams must establish at least a few common interfaces, both organizationally and technically.
Use cross-functional teams – Consider using cross-functional teams to develop and deploy cloud infrastructure. Gone is the day (or at least should be) where security requirements are delivered before a project begins, then validated after the project finishes. It’s now a shared responsibility.
Set the right foundation – Create common building blocks that meet requirements and can be leveraged across projects with your newly cross-functional teams. For example, with the right building blocks in place, a developer can code access to a data source without considering credentials or encryption, because the connection is authorized by role and policy. This also reduces the complexity of code dramatically, thereby reducing your risk of breach-enabling defects.
Forget Patch Tuesday – CI/CD pipelines in cloud-native technology facilitate rapid change of validated changes with greatly reduced risk of downtime. Consider continuous patching, or at least as close to real time as possible.
Leverage automation – The key to successful governance and compliance is automation. I specifically recommend starting with repeatable and templated provisioning and deployment artifacts. Ones that are designed to meet the requirements of the security architecture, and further ensure that deviance from requirements is blocked or flagged.
Security
via https://www.aiupnow.com
Help Net Security, Khareem Sudlow
