Blumetech's Tech Blog

AWS Security and Blumetech Clients

Customers frequently tell us that they want to be fully secure when they migrate to AWS. As anyone with a good security background would tell you, being "fully secure" is a relative thing. For example, the level of security for our publishing clients is probably not the same level of security for our financial clients. Their risk tolerance related to security have two vastly different profiles.

On one end of the spectrum we have customers that are perfectly happy with the bare minimums delivered at the lowest possible cost and the least management and user burden. We have other customers where security is job #1. Cost is no object to protect their assets. Many of these firms have regulatory requirements that force them to implement various security measures.

In this post I wanted to cover this security spectrum at a high level from security basics to what can be done for the most extreme security conscious firm. We work with our customers to find the most appropriate spot for them on this spectrum.

The Basics

Any AWS account that Blumetech sets up and manages for you will include all the following:

1. Strong passwords on all IAM accounts
2. Dedicated IAM accounts for roles, e.g. Billing Admin, Read-Only User, etc. We use IAM profiles to enforce the standard "least-privilege" model
3. A battle-tested VPC design that we have used successfully for years at dozens of customers
4. Secure private dedicated networks for instances that are unreachable from the Internet
5. Enable CloudTrail to monitor and log all AWS API calls
6. Create an S3 Logging Bucket with an appropriate policy for security and retention to hold all incoming logs
7. Use AWS Security Groups to enforce "least-privilege" at the network layer for each instance

Advanced

"The Basics" cover roughly 60% of our customer base.  Some customers want to leverage more advanced features that come natively on the AWS platform. For those customers that want additional security controls, we typically recommend a combination of the following additions to "The Basics"

1. Lock away root account credentials. Store the credentials in a safe place never to be used except in an emergency. Use IAM accounts instead
2. Remove all API access keys to the root account
3. Enable Multi-Factor Authentication on IAM accounts. This can be for all IAM accounts or a privileged subset
4. Enable Multi-Factor Authentication on AWS Workspaces login
5. Enable periodic password rotation on IAM accounts.
6. Use IAM Profiles for all application. If not possible, force periodic API access key rotation.
7. Enable EBS volume encryption at rest using AWS Key Management Service
8. Enable S3 encryption at rest using AWS Key Management Service
9. Run periodic vulnerability scans of Internet facing instances

Expert

Rarely we run into customers who need additional security controls. Typically when we get to this level we will require some kind of custom solution tailored to either the customer's own needs or some regulatory requirement, e.g. HIPPA. At this level there aren't any simple "cookie-cutter" solutions. An in depth analysis is required to understand what security features are necessary.

In some cases the discussion moves into whether or not the customer trusts the AWS platform itself. This lack of trust may become apparent in either a lack of trust in AWS security itself, i.e. AWS's own security and compliance procedures, and/or a lack of trust in the platform, e.g. a customer may be concerned that in a multi-tenant environment other AWS customers may be able to access their data.

In these situations we may recommend any of the following security controls :

1. Implementing a Security and Compliance 3rd Party, e.g. Evident.IO
2. Implement a Bring-Your-Own-Key security model where customers provide their own data encryption keys
3. Implement SafeNet to encrypt data at rest for any instances
4. Use dedicated hosts to avoid any fear of "cross-talk" between instances from other customers.
5. Implement Web Application Firewalls from TrendMicro, AWS, etc.
6. Implement Intrusion Detection and Intrusion Prevention Systems (IDS/IPS)
7. Build a DevSecOps practice to automatically monitor, alert, and respond to security related events

Microsoft Hosted Exchange Outage

When the system works, it is great and well worth the cost of the service.

Today's outage is frustrating for both users as well as the IT professionals trying to support the service.

We have several accounts using the service each with a different experience today.

The outage left one client's email completely shut down for a few hours - the Office 365 health status did reflect that Exchange was down.

Another client experienced no disruption and yet another had intermittent issues but the Microsoft console showed all services to be healthy.

You can check the Office 365 service health status here:

http://status.office365.com/ or log into the admin management console.

http://www.crn.com/news/cloud/300073234/microsoft-suffers-another-cloud-outage-as-exchange-online-users-left-in-the-lurch.htm

We still like the service and hope this outage doesn't become a pattern.

 

Related articles

 

Microsoft's Office 365 outages pile up: Growing pains or uptime issues?

Posted with Blogsy

Windows 2012 Features SlideShow

Network World has published a slide show on the major highlights of Windows 2012. Unfortunately there isn't much in the release that makes the upgrade pressing.

Some key features for SMB:

1. Resilient File System (ReFS) -- Win2012 will have a new file system beyond just NTFS. The new file system supports more storage and the stability requirements needed when you go beyond 256TB. This feature really only applies to those SMBs with multi-TB volumes.
2. Data Deduplication -- This is a common feature on many storage arrays, but many SMBs have simple DAS without this advanced feature. For a basic file server, dedup can reduce space by up to 40%. Dedup volumes can also be used as backup targets for additional savings

There are some other features that I would define as specialty cases that don't apply to all SMBs. For example there were improvements related to Hyper-V. (I don't know anyone running Hyper-V. ESX, RedHat, and Xen only) Also some improvements on IIS for heavy loads. (I don't know anyone running IIS under heavy loads. (Apache and Nginx for heavy loaded web servers.

Link to Slide Show