Apps

Security policies need to be updated to include the cloud

Nick Hardiman suggests the ways in which a security policy needs to be updated when your organization moves any systems or applications to the cloud.

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.

About

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 ...

3 comments
Deadly Ernest
Deadly Ernest

of what transits the cloud. If you have no need for high level security, then it's not an issue, but it's a big issue for high security situations as the data can easily be intercepted while travelling between your location and the cloud server farm. The oldest form of electronic data intercept is the phone tap, and it also works for most of today's communication systems. Sure you can use encryption, but the signals are still open to interception and then decryption efforts by those who wish to take the time an effort. Another aspect is the security checking and vetting of the staff who may come into contact with that data at the cloud server farm. If you have to have all who may come into contact with the data checked, who gets to pay for all those extra staff at the service provider? Don't forget these issues when thinking cloud services.

cpr
cpr

We must make a distinction between policy and procedures (standards, guidelines, etc.). A policy states "what" is to be done. It should be a high-level document that is immune to many types of changes, such as technology, ownership, management, reorganizations, etc .A procedure describes "how" the policy is emplemented. It describes how the policy will be used, who will use it, who is responsible for it, how it is changed, basically, the nuts and bolts. As an example, a company employee is issued a computer login configuration, consisting of a user-id and password. The policy might say that each employee is responsible for the usage of their own logins, must change their password on a regular basis, could be fired for misuse, cannot use it to access non-authorized computers, etc. The procedure might define how long the password will be, any repeating/special characters, how often the password gets changed, etc. In this manner, if the underlying computer systems change, then the processes will change, and not the policy. The policy is approved by senior management, but middle management is tasked with the implementation and day to day workings. Data security policy should not need to identify where the data is located, but rather state that data is to be classified, and certain data is to have limited, authorized access. These are just a few items, but I strongly believe that you must separate policy and proceedures. Traffic rules have been around for many years, but none (of at least very, very few) talk about specific automobiles. And the reason is that they don't discuss the implementation of the traffic rules, they let the law enforcement agencies enforce the policies. If companies developed policies, then a lot of this type of 'wandering' could be avoided. Just my $0.02 worth. MM

Nick Hardiman
Nick Hardiman

I think that's what both these comments tell me. good policies and procedures, bad eavesdropping - perhaps we can learn lessons from past waves of computing?