Every Internet service is the subject of automated cracking attempts many times a day. An SSH server suffers constant attempts at a root login. A website endlessly processes dodgy requests for insecure apps that were patched long ago - or were simply never installed. A firewall continuously drops the packets of port scans. IT security is a big area, covering everything from brute force attempts to guess a password, to laptop theft and denial of service, to over-exposure on social media.
The security of enterprise technology is maintained by security professionals, tools, and policies. Nothing beats having a dedicated team of security professionals, armed with excellent security tools, watching the network at all times for attacks. What the security team can do is governed by the IT security policy (and I'm not talking about application policy, such as group policy rules in AD - I mean the fat governance document approved by the enterprise chiefs). Every enterprise needs policies — a policy is to an enterprise what a config file is to an application.
The clunky old enterprise IT security policy
Every enterprise has an IT security policy. The policy lists all sorts of properties that are desirable, such as system authorization, key management, and e-mail abuse. The policy has to cover a lot of ground so it is kept high level. The policy was built up over time, is controlled by a head office, and can only be updated by the authorized few. In a traditional enterprise, this leads to a document that is a little awkward to work with.
- The policy may mention appropriate encryption, but it won't mention what type, who supplies it, or where it happens.
- The policy may name classifications for documents (usually a variation on top secret, secret, confidential, and open) but not describe how data get classified.
- The policy may describe the roles and responsibilities of employees but not what they have to do. Who hasn't signed a compliance document ordering us to expose any dirty little secrets of our colleagues?
A slick new cloud security policy
The security policy may be a little clunky, but it probably works just fine within the enterprise because years of use have led to the holes being filled and the wrinkles smoothed out. But what about outside the enterprise, when an enterprise benefits from using others' cloud services, and deploys its own services to a public cloud? Since a security policy is old and cloud computing is new, there is a good chance the policy is out of touch - it just doesn't work with the cloud. Examples include spraying confidential employee details across a hundred cloud-based services, omitting intrusion detection when building a new cloud service, and losing data when a cloud vendor disappears.
A good example of on-premise security vs. cloud security is the website pentest. A website owner, worried about the security of her system, is reassured by regular penetration testing. In the traditional data center, there are two parts to this test: a back-end infrastructure test and a front-end service test. Scanners probe, sniffers record, and hack tools exploit. At the end of the test, out pops a list of the vulnerabilities to review. This kind of pentest just does not work with Amazon Web Services.
AWS has a shared responsibility model, which basically means there is no way you are getting near their infrastructure. Back-end pentests just can't be done. If this lack of testing goes against an enterprise security policy and no-one is brave or foolish enough to sign a security waiver, that enterprise is not going to use AWS.
The cloud security realm
Cloud security will always be central to cloud use. The traditional enterprise IT security policy must be overhauled to cover cloud computing.
New cloud security tools are appearing to fill the gaps caused by the new disruptive technologies. These new tools help to apply the old work of vulnerability scans, data encryption, log analysis, and firewall configuration to the new cloud deployment models.
Who are the best people to use these new cloud security tools? The old security professionals. An enterprise doesn't need new players for this new cloud security game.
Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the designers and developers who build the top layer that customers use.