It's log, it’s log, it's better than bad, it's good!
Everyone wants a log! You're gonna love it, log!
Come on and get your log! Everyone needs a log!
– Ren & Stimpy
Whether we like it or not, logging, monitoring and alerting are realities that we have to deal with on a daily basis. This is especially true for organizations that have legislative, regulatory or governance requirements that specifically call for logging.
Besides regulations, logging is extremely important for operations and security teams to do their jobs, not to mention technical support, QA and dev. Fortunately for folks migrating their applications to the cloud, there are, no real differences in terms of logging, monitoring or alerting from an on-premises deployment of the same applications— with two key exceptions.
These two key differences are both more prominent when dealing with the public cloud. The first is that most (all?) public cloud providers don’t make logs of user actions at the API or console available to the consumer. This means that you can’t track who actually performed actions such as starting up or terminating an instance or perhaps even more importantly, who created or changed firewall or other security rules. This has some serious implications under any number of compliance or regulatory regimes, including PCI and Sarbanes-Oxley to name two.
Along similar lines, consumers of public cloud want to get logs from their instances or applications without having to open up access from the broad range of potential IPs to their log consolidation or SIEM platforms.
Fortunately, there are architecturally simple solutions to both of these problems.
In the first case of getting API or console logs from your providers, what you need to do is purchase (or build) and then deploy a proxy between you and your cloud provider. Then, use that proxy for all API or console connections. Next, configure the proxy to log whatever is relevant to your organization and pass those logs to your log management servers. This architecture has other advantages (as I mentioned in my previous post) because you can also leverage the proxy to enhance the levels of authorization made available by the CSP. Additionally, the proxy can be configured to regularly audit the cloud environments and to alert when the configuration changes from what the proxy thinks it should be. This is handy as it means either someone has gone around the proxy to make changes or that something has failed on the cloud provider’s side of things.
The second case, getting instance or application logs from the provider back to your log management infrastructure has a few different options to choose from, depending on your requirements. The first option is to leverage the above proxy along with firewall APIs to automatically open the necessary IPs and ports for instances as necessary. This way you have a more limited range of IPs/ports open at any time. Alternately, a tiered log management structure could be built where logs are centralized into one or two instances on a cloud provider and the logs are then forwarded to the log management server.
In either case, an existing operations or security agent can be leveraged to direct the logs to the correct place using the agents’ central server. Finally, a pull mechanism would be used where the log management server regularly polls the cloud servers and pulls the logs down. Each of these options will work well; however, an organization needs to evaluate its own resources and see which one will be easiest for them to manage.
If one of these two issues is addressed by your organization, you are one big step closer to being able to use clouds like the enterprise that you are. Next post, I’ll be talking about another important aspect that needs addressing—key management.
David Mortman is the enStratus Chief Security Architect and has been doing Information Security for well over 15 years. Most recently, he was the Director of Security and Operations at C3. Previously, David was the CISO at Siebel Systems and the Manager of Global Security at Network Associates. David speaks regularly at Blackhat, Defcon and RSA amongst other conferences. Additionally, he blogs at emergentchaos.com, newschoolsecurity.com and securosis.com. David sits on a variety of advisory boards such as Qualys and Virtuosi. He holds a B.S. in Chemistry from the University of Chicago and bakes, cooks and juggles in his spare time.
