Tips on Cloud Security Vol. 3: 7 Core Requirements for an AWS Cloud Security Strategy

Cloud privacyIn the recent post on “Establishing an Amazon Web Services (AWS) Cloud Security Strategy,” I introduced some of the adoption challenges Cloud Service Customers looking to strengthen their cloud security posture are facing. While designing and maturing a Cloud Security Program can be complicated and challenging, I can recommend a baseline for beginning. The following high-level infrastructure and operations capabilities serve as 7 core requirements when designing a cloud security strategy.

1)    Account Management

All organizations using AWS should evaluate whether their monthly AWS spend can be identified and described. The inability to do so may be indicative of loose provisioning controls within AWS account(s) and/or poor governance around IT infrastructure expenditures. AWS has simplified cost controls through CloudWatch billing alerts, a price list API, daily usage reports, consolidated billing and the support of cost allocation tags which allow for full programmatic integration with other SaaS technologies.

How many AWS accounts does an organization need?

With the support of Consolidated Billing and AWS’ decision to include the AWS account number as an identifying factor within the Amazon Resource Name (ARN), an organization can simplify security controls and policies and gain greater flexibility by using several distinct AWS accounts. However, owning multiple AWS accounts is not a security requirement and a strong security posture can be established through a single AWS account.

Takeaway: Identify the number of AWS accounts needed and their owners, and integrate using consolidated billing. Create CloudWatch Billing Alerts.

2)    Identity Federation

Any organization using AWS is guaranteed to have multiple services in use. For example, GitHub, Google Apps, Office 365, Salesforce, Asana, Mavenlink, etc. Managing user accounts in every service is not only an administrative challenge, but also presents a vulnerability as users are added and removed from the organization. AWS supports centralized user administration through authentication using a SAML 2.0 compliant identity provider.

For smaller organizations, such as early adopters, services such as OneLogin and Okta provide online identity management services that provide centralized user administration capabilities. For the enterprise organization running Microsoft Active Directory, AWS supports AD FS as an identity provider using SAML 2.0. Additionally, AWS supports multiple options such as synchronization with an on-premise Active Directory, an Active Directory compatible instance hosted in AWS, and most recently, a managed Active Directory service.

Takeaway: Identify an identity provider and configure identity federation.

3)    Tagging Strategy

Tagging in AWS is critical to cloud security because it provides resource identification in an agile environment where resources can be scaled automatically at any time. Additionally, tagging supports asset classification and can be leveraged within Identity and Access Management (IAM) policies to provide appropriate controls defined by organizational data classification policies. Tagging is also a critical component of auditing capabilities within AWS. As resources are provisioned, terminated and modified, tagging supplements the infrastructure inventory collection process.

Takeaway: Define an organizational Tagging Strategy to facilitate resource identification and inventory based on data classification policies and other data access controls defined by the organization.

4)    Identity and Access Management Policies

At the root of AWS security are IAM policies. IAM policies enable organizations to control access to AWS services and resources using either AWS provided policies or custom policies written and owned by the organization. IAM policies will allow or deny access to users, groups and roles based on the requirements defined by the organization.

Takeaway: Define a least privilege and default-deny security model for the organization and create IAM policies to coincide with organization policies. Assign IAM policies to IAM users, groups and roles.

5)    Event Logging and Alerting

Accountability and auditing is critical to a security strategy in that it provides visibility to the organization. One method that introduces visibility to the organization is event logging and alerting. AWS CloudWatch and CloudTrail are available for many AWS services and monitor various levels of the infrastructure in order to track changes and events occurring within the network stack, resource provisioning and de-provisioning and calls to the AWS API. The AWS Simple Notification Service (SNS) facilitates forwarding these events to responsible teams and integrates with other services such as Splunk. Enabling AWS Config also provides configuration history and relationships between AWS resources. Modifications to AWS resources such as changes to available ingress and egress controls are logged through AWS Config.

Takeaway: Enable CloudTrail, Config, VPC Flow Logs and CloudWatch Logs. Create and subscribe to notification topics to alert organization of changes within the AWS infrastructure. To go one step further, integrate logging with other services such as Splunk or SumoLogic.

6)    Remote Access

Securing remote access into AWS may be one of the first controls identified by enterprise cloud service customers for communication between on-premise services and cloud resources. Additionally, this may be one of the first controls an enterprise is ready to implement by integrating with an on-premise VPN solution. However, smaller organizations may not have an on-premise solution. Nevertheless, there are cloud-ready VPN solutions available that are fully supported within AWS. Many of these services can be found in the AWS Marketplace.

Takeaway: Disallow direct access to VPC resources and require VPN technology to access AWS resources configured within a VPC.

7)    Identify a Trusted Advisor

The cloud infrastructure will grow as the needs of the business evolve. Additionally, as AWS continues to add cloud services, organizations will need to ensure that cloud security strategies grow to cover the AWS footprint. AWS Trusted Advisor identifies (at a high-level) gaps against best practices in cost optimization, security, fault tolerance and performance improvement. AWS Trusted Advisor identifies over a dozen best practice security configurations and serves as a basic baseline recommendation tool; however, it cannot provide an in-depth analysis of a customer’s AWS environment. In order to strengthen the overall security posture, organizations should consider partnering with a Cloud Security company with proven expertise in the customer’s chosen CSP cloud infrastructure.

Note: AWS Trusted Advisor requires a premium support plan with AWS.

Takeaway: Identify a trusted advisor that understands your AWS environment and business goals.

Conclusion

There are many fundamentals to a Cloud Security Strategy that include encryption, compliance, risk management, application delivery, disaster recovery and more. Additionally, the core requirements identified in this Tip on Cloud Security will have a greater likelihood of success when they include existing organizational security strategies and input from their respective teams. Nevertheless, as organizations begin to deploy in the cloud (and specifically within AWS), having a core set of requirements to begin the discussion will help introduce cloud security early in the project’s lifecycle. 

Stay tuned for an upcoming post where we’ll review and discuss “Cloud Security Platforms.”

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Cisco Patches Four Backdoors

Overview

The end of 2015 posed a busy backdoor day for Cisco engineers, as four major vulnerabilities, CVE-2015-6314, CVE-2015-6317, CVE-2015-6323 and CVE-2015-6336 were published and later patched in mid-January 2016.

In late December 2015, Cisco announced in a security blog an Update for Customers, explaining an additional code review and penetration testing to address public concern after the Juniper ScreenOS Vulnerabilities. Cisco’s efforts seemed to pay off with four vulnerabilities posted on January 13, 2016 in the Cisco Security Advisory and Responses.

Impact

The Cisco Security Advisory points out all four vulnerabilities have no possible workarounds. The Cisco Exploitation and Public Announcements states for the four vulnerabilities, “The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory.”

The four backdoors cover several Wireless Controllers, Access Points and the Identity Services Engine. Below is an outline organized by CVE and lists the devices affected.

  • CVE-2015-6314
    • Cisco 2500 Series Wireless Controllers
    • Cisco 5500 Series Wireless Controllers
    • Cisco 8500 Series Wireless Controllers
    • Cisco Flex 7500 Series Wireless Controllers
    • Cisco Virtual Wireless Controllers
  • CVE-2015-6317 & CVE-2015-6323
    • Cisco Identity Services Engine
      • Vulnerable Versions
        • 1.1 or later
        • 1.2.0 prior to patch 17
        • 1.2.1 prior to patch 8
        • 1.3 prior to patch 5
        • 1.4 prior to patch 4
    • Cisco Identity Services Engine Express
  • CVE-2015-6336
    • Cisco Aironet 1830e Series Access Point
    • Cisco Aironet 1830i Series Access Point
    • Cisco Aironet 1850e Series Access Point
    • Cisco Aironet 1850i Series Access Point

The critical Cisco Wireless LAN Controller Unauthorized Access Vulnerability CVE-2015-6314 could allow an unauthenticated remote attacker ability to modify configurations.The medium-rated Cisco Identity Services Engine Unauthorized Access Vulnerability CVE-2015-6317 applies to versions prior to 2.0 and allows a low-privileged authenticated remote attacker access to particular web resources intended only for administrative users.

The critical Cisco Identity Services Engine Unauthorized Access Vulnerability CVE-2015-6323, with access to the Admin portal, can allow an attacker administrative access to the device.

The high-rated Cisco Aironet 1800 Series Access Point Default Static Account Credentials Vulnerability CVE-2015-6336 could be accessed with non-administrative privileges using a default account that has a static password. The default account is created when the device is installed.

Remediation

With no workarounds and the levity of these backdoors, it is important patch as soon as possible.

For Cisco WLCs, the Cisco Security Advisory (id cisco-sa-20160113-wlc) recommends upgrading to an appropriate release indicated in the table below.

Cisco WLC Major Release First Fixed Release CVE-2015-6314
7.6 Contact Cisco TAC
8.0 8.0.121.0
8.1 8.1.131.0

 

Both Cisco Security Advisory (id: cisco-sa-20160113-ise2) and Cisco Security Advisory (id: cisco-sa-20160113-ise) recommends upgrading to Cisco Identity Services Engine 2.0 or above.

The Cisco Security Advisory (id cisco-sa-20160113-air) recommends upgrading to version 8.1.131.0 or later for the Aironet 1800 Series Access Points.

GuidePoint Security is available to assist our customers with any remediation efforts. Please contact your Account Executive or click here for more details on how GuidePoint can help.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

 

FortiOS SSH Undocumented Interactive Login Vulnerability

Overview

Where security research is concerned, when a vulnerability or undocumented access has been found on one device, attackers and security researchers scramble to find related vulnerabilities in similar devices. Merely weeks after vulnerabilities were found in the Juniper ScreenOS, another similar vulnerability, CVE-2016-1909, was found in Fortinet’s FortiOS. CVE-2016-1909 is a hardcoded SSH credential with the username Fortimanager_Access and a static string FGTAbc11*xy+Qqz27 hashed as the password.

Impact

FortiOS versions from 4.3.0 to 4.3.16 and 5.0.0 to 5.0.7, or builds between November 2012 and July 2014, include the hardcoded SSH credentials. FortiOS 5.2 and 5.4 are not affected. The Seclists.org Full Disclosure mailing list posted proof of concept code, and some Twitter feeds document exploits as early as January 12, 2016.

The hardcoded credentials give administrative access and may be tied to FortiManager Centralized Security Management due to the lack of event logs.

Fortinet’s blog, Behind the Firewall, posted a Brief Statement Regarding Issues Found with FortiOS, stating, “After careful analysis and investigation, we were able to verify this issue was not due to any malicious activity by any party, internal or external.” The blog identifies the following versions as not affected:

FortiOS v4.3.17 or any later version of FortiOS v4.3 (available as of July 9, 2014)
FortiOS v5.0.8 or any later version of FortiOS v5.0 (available as of July 28, 2014)
Any version of FortiOS v5.2 or v5.4

Note: there have been reports of researchers finding the hardcoded password string in version 5.2.3, suggesting the hashing algorithm to produce the final password may have been altered throughout different versions.

Identification

It is difficult to identify unauthorized access because FortiOS does not create event logs for the Fortimanager_Access user by default. It may be possible to enable logs to include the user Fortimanager_Access by configuring Local-In Policy to include central management (a FortiGate unit being managed by a FortiManager unit). See the Logging Local-In Policies section in the FortiOS Handbook Logging and Reporting for FortiOS.

It may be possible to view SSH attempts in the console. Use “diagnose debug application sshd -1” to identify input_usrauth_requests for the Fortimanager_Access user.

Remediation

FortiGuard Center Advisory post, FortiOS SSH Undocumented Interactive Login Vulnerability, recommends patching FortiOS branch 4.3 to 4.3.17 or later, and FortiOS branch 5.0 to 5.0.8 or later. There are two possible workarounds:

  1. Disable admin access via SSH on all interfaces, and use the Web GUI or console applet of the GUI for CLI access.
  2. Limit SSH access to a minimal set of IP addresses with the Local-In policies.

GuidePoint is recommending whitelisting IP addresses with SSH access to your FortiOS device and patching to the latest build.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Tips on Cloud Security Vol. 2: Establishing an Amazon Web Services Cloud Security Strategy

Nearly ten years ago, Amazon officially announced that they would be selling computing time and storage capacity, and over a decade since Simple Queue Service (SQS) was launched in 2004. Since then, Amazon Web Services (AWS) has developed hundreds of new services comprising Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) solutions, and became the go-to Cloud Service Provider (CSP) for early adopters such as startups, small and medium-sized businesses and nimble organizations. Organizations that took to the cloud soon after its inception have had time to mature cloud operation methodologies and form business culture around agile and continuous delivery solutions.

Despite the explosive growth of AWS’ market share, the enterprise market has only recently begun considering public CSPs as a viable infrastructure hosting option. Extending the enterprise data center to a public CSP is not only an architectural challenge; it also requires risk and compliance considerations that must be evaluated in order to avoid weakening the security posture of the organization. Moreover, security architects must understand how to translate existing controls, maintain visibility and adapt to a new technology while ensuring that speed of delivery and agility are not compromised.

Cloud Security Considerations for Early Adopters and New Customers

Despite continued cloud usage, many early adopters are asking the same questions as enterprise customers who are just beginning their journey into the public cloud. Organizations with a great deal of experience with AWS are asking “What do we secure?” while enterprises new to public cloud services are asking “How do we secure?” Below are a few prevalent challenges and considerations of both groups seeking to secure public cloud environments:

Common Challenges and Considerations

Screen Shot 2016-01-07 at 1.01.43 PM

 

 

 

 

 

 

While there isn’t a complete out-of-the-box cloud security solution that serves everyone equally, AWS has made significant progress in making resources available to assist with implementing a cloud security strategy. Less-regulated cloud service customers who have designed products for the cloud may find native AWS tools convenient and easily integrative with current cloud infrastructure. However, building an adequate security strategy can be complicated and challenging for an enterprise customer, given that AWS tools may not be sufficient for a mature security program. However, as enterprise applications and infrastructure are being architected and engineered for AWS, the enterprise cloud service customer will be able to use cloud-native solutions within their security strategies.

Cloud Security is a Shared Responsibility

Both the early adopters and enterprise organizations must have a strong understanding of the Shared Responsibility Model. The Shared Responsibility Model helps identify the boundaries between cloud service provider and customer security responsibilities. As organizations begin to develop cloud security strategies, identifying obligations is a critical success factor.

shared_responsibility

 

 

 

 

 

 

 

 

 

 

 

 

 

*Source: https://aws.amazon.com/compliance/shared-responsibility-model/

Responsibility boundaries shift when moving between IaaS, PaaS and SaaS. While a CSP may be responsible for certain layers of the cloud platform, cloud service customers must remain knowledgeable of where their own responsibility lies. Before moving to AWS, early adopters may not have had to consider infrastructure requirements below the application and data layers; however, they are now responsible for the security of additional layers. Conversely, the enterprise organization is accustomed to owning security at all layers, but can be relieved of managing layers such as physical security and the core network.

Conclusion

Cloud security is a similar challenge to traditional on-premise security when data centers were first being built; proper security practices were often an afterthought. An additional complication to cloud security is the elasticity of the cloud. A cloud environment can become difficult to manage very quickly, and success will also depend on an organization’s ability to maintain visibility within such a dynamic environment.

Designing a comprehensive cloud security strategy within AWS will require adapting controls and risk management methodologies to an agile operations model, as well as understanding of how to utilize the resources available for maintaining visibility. Lastly, it is imperative for those new to the public cloud to understand that boundaries may shift as organizations leverage IaaS, PaaS or SaaS solutions.

Stay tuned for an upcoming post where we’ll review and discuss 7 Core Requirements for a Solid Cloud Security Strategy.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.