Building Energy Security Framework

Building Energy Security Framework Philosophy, Design, and Implementation Building Energy manages multiple subsets of customer data. Customers have strict requirements for regulatory compliance, privacy safeguards, and data integrity. Building Energy takes these requirements very seriously and has architected the Building Energy application system to be extremely secure. This document describes the security philosophy, design, and implementation of the system including the risks mitigated, security controls in place, and contingency plans for extenuating circumstances. Less is More The key mantra of Internet security is Less is More. Fewer moving pieces and exposed points of access means fewer opportunities to access a system in an uncontrolled manner. From an external viewpoint, the Building Energy website is exposed as a web application accessible only via HTTPS for logged-in users with valid accounts or API access keys. There are no other ingress points for access by application users and no other components of the application are exposed to the public Internet. 1

Security Layers The Building Energy application is segregated into three layers: Layers 1, 2 and 3. The security layers are arranged like layers of an onion: Layer 3 wraps Layer 2, which in turn wraps Layer 1. Layer 1 is the innermost and Layer 3 is the outermost. Layer 3 cannot access Layer 1; interactions must pass through Layer 2. The following diagram illustrates the logical layered nature of the application. Layer 3 Only Layer 3 is exposed to Internet traffic. This outer layers consists of only two components: an Amazon Web Services (AWS) Elastic Load Balancer (ELB) that handles user HTTPS traffic, and an OpenVPN server that is accessible only by Building Energy developers who have valid VPN keys and valid two-factor authentication device access codes. For key management purposes, the OpenVPN server can only be accessed via SSH from the Building Energy physical office network and requires valid SSH keys and two-factor authentication device access codes. All other access protocols are denied by AWS access firewall rules. Layer 2 Layer 2 contains the web application and data processing resources. It is only accessible via the AWS ELB or the VPN server. AWS network firewall rules prevent all other possible points of Internet traffic ingress from accessing the application resources. Layer 2 applications can make egress access to the Internet, so resources can be updated, patched, and can fetch external data, but no external systems can make ingress traffic to the application other than via the ELB or VPN server. 2

Layer 1 Layer 1 is the core layer of the system which contains the master and replica database systems. Layer 1 is firewall accessible only via the application resources in Layer 2. No external ingress or egress traffic from the Internet is permitted to Layer 1 in any way. It is physically impossible for an external actor to access the database resources in Layer 1 without first defeating the AWS ELB system or the VPN server, then defeating the access controls to the application Layer 2, then defeating the access controls to the database Layer 1. Risk Assessment for Defeating Layers As detailed above, defeating Building Energy s security framework would requires multiple access factors to penetrate multiple layers. To defeat Layer 3, and attack would have to either defeat Amazon s industry leading Elastic Load Balancer system, or defeat Building Energy s VPN server. This document will work on the assumption that Amazon takes their ELB security very seriously and that defeating the ELB is a risk mitigated by Amazon s considerable security personnel and is essentially impossible. Even if it were the case the ELB could be defeated, it would go no further than the upstream HTTP port on the Building Energy application, which would provide no unauthorized data access. Attacks on the BE VPN would require multiple attack angles. First, the attacker would need to procure a valid BE VPN key. These keys are stored on encrypted, password-protected hard drives of the BE developer s laptops. Second, the attack would need a valid two-factor authentication device code. Last, the attacker would need a valid SSH key to access the application servers in Layer 2. This means an attacker would need five discrete, separate physical and data resources to succeed: 1. A Building Energy developer s laptop 2. That specific developer s hard drive password 3. That specific developer s VPN key 4. That specific developer s two-factor authentication device 5. That specific developer s SSH key All five of these factors MUST be acquired by an attacker in order to succeed. If any one or more of these factors are not present then the attack has no access to Layers 3 or 2. Layer 1 is protected by physical firewall rules that allows only access to the computing resources in Layer 2. Database access is also password protected, and encrypted over SSL. All traffic between Layers 2 and 1 are passed only on private 10.0.0.0/24 IP addresses, completely unroutable and inaccessable by external Internet traffic. 3

Physical Network Security Amazon provides powerful network security and isolation tools that Building Energy leverages to the maximum to ensure total system security (http://aws.amazon.com/security/). The first layer of security provided by AWS is Identity and Access Management (IAM http://aws.amazon.com/iam/). All access to the Amazon management console is controlled via IAM users and roles. All Building Energy developer and security teams must use two-factor authentication devices to access the console, and only the minimal permissions necessary to manage their role in the system are provided to users. Furthermore, automated deployment tools are also users in a sense via the Amazon API. Deployment tools are granted only the very minimum permissions necessary to deploy a Building Energy stack. For example deployment tools can create specific resources, but they cannot create or change any user privileges. The second layer of physical security provided by AWS is called a Virtual Private Cloud (VPC http://aws.amazon.com/vpc/). VPC are isolated network containers, that cannot be accessed by any other AWS customers or systems. Resources on the VPC do not have public IP addresses, but instead have private network addresses in the 10.0.0.0/24 private network block. This block is unroutable by public Internet routers as defined in RFC 1918. The third layer of security provided by AWS are called Availability Zones (AZ http://docs.aws.amazon.com/awsec2/latest/userguide/using-regions-availability-zones.ht ml). AZs are physically separate facilities managed by Amazon, physical access to one AZ cannot be accessed via another. Amazon physical security requires strict measures, including biometric access to physical resources, so that only valid and authorized Amazon personnel ever have access to physical computing resources. Building Energy spreads its resources between AZs to leverage this strong level of physical access control. The fourth layer of physical security provided by AWS are called Subnets (http://docs.aws.amazon.com/amazonvpc/latest/userguide/vpc_subnets.html). Subnets divide up VPCs into separately managed and firewalled network segments. Using firewall rules, access between subnets can be strictly controlled, so that subnets that contain, for example, Layer 2 application resources, can only talk to Layer 1 database resources, and all other access modes are denied. The Building Energy system is contained in a VPC, and broken down into three subnets as detailed in diagram 2. The Layer 2 subnet is considered Public because it can be accessed via Internet traffic coming from the ELB or VPN. The other two subnets are marked Private because they are inaccessible by any external systems. 4

This physical diagram maps to the logical diagram discussed at the beginning of this document. The security layers are divided by firewall dashed lines. The three firewalls in this document correlate to the three layers in the logical diagram above. System Software Security The foundation of Building Energy s system software security is AWS. Amazon has an extensive security framework in place that safeguards both Amazon and its customers, including: HIPAA SOC 1/SSAE 16/ISAE 3402 (formerly SAS70) SOC 2 SOC 3 PCI DSS Level 1 ISO 27001 FedRAMP(SM) DIACAP and FISMA ITAR FIPS 140-2 CSA 5

MPAA Building Energy leverages AWS resources as much as possible in order to take advantage of these security enhancements (http://aws.amazon.com/compliance/). For example, the Building Energy database is hosed in Layer 3 on an AWS Relational Database Service (RDS) resource. This resource is managed entirely by Amazon, which has access to pre-disclosure security exploit patches and works closely with the Postgres and Linux security teams to ensure that the systems are patched before exploits are released into the wild. Combined with the layered security features described above, this makes for an extremely secure database system. Another resource Building Energy leverages from Amazon is ElastiCache. Instead of running, maintaining, patching and monitoring our own cache servers, Building Energy offloads that work to the AWS teams, which in turn have much higher levels of security resources and access to developers to prevent exploits from ever being exposed on AWS. Like the RDS above, Building Energy also keeps these cache resources in Layer 1, preventing unauthorized access. The Building Energy Application is the only resource not managed by AWS, but Building Energy still applies the same security procedures that Amazon does. Building Energy runs on the most recent and stable Ubuntu Linux release, 13.10. Upstream security patches are automatically applied every day. Building Energy uses industry-standard application security tools (AppArmor) and intrusion detection tools (tripwire) to ensure that applications cannot break out of their security containers, and that no system files changes or additions are made by unauthorized actors. In the event of an unauthorized change or addition to the system, the tripwire intrusion detection system will alert the Building Energy security team, whose mitigation policy is to suspend and isolate the system, restore the system from a point in time before the intrusion detection, and do post mortem analysis of the intrusion vector and what steps need to be taken to address the issue. It is important to point out that an intrusion has never been detected on the Building Energy system, and is highly unlikely given the multi factor authentication required to access system. A final physical defense is the replication of database snapshots across multiple AWS regions. In the extremely unlikely event of total regional failure a new Building Energy site can be bootstraped and deployed in less than three hours. Application Level Security 6

All user access to the Building Energy Application requires a valid login and password. These credentials are sent via HTTPS only, and cannot be intercepted in the clear by network intrusion or man-in-the-middle attacks. The application is developed with the Django python web application framework, which has extensive use in the industry by thousands of large-scale production websites and is considered to be highly secure. Building Energy also takes a proactive approach to mitigating newly revealed security vulnerabilities. First, all system software, packages, and kernels are scanned every day to ensure that they are up-to-date with the latest upstream security patches from the OS vendor, who has access to security vulnerability reports before they are made public. Building Energy also does file integrity scans on all servers every hour to ensure that critical system files do not change and that no new files are installed on the system without authorization. Last Building Energy performs network port scans to ensure that only the HTTPS port is exposed on its site and that there are no other points of access. Perhaps the most common form of web application attack is SQL injection. Building Energy uses several techniques to render this style of attack harmless. First, Building Energy generates no SQL code all code and parameters are passed in via the Django framework, which very carefully quotes all SQL parameters so they can never be interpreted as code. Additionally, Python s runtime dynamic-typed nature means that common attack techniques like buffer overflows and stack-busting are essentially impossible. Idle users are automatically logged out after 15 minutes of inactivity, and all HTTPS traffic connections at the TCP level are disconnected after 60 seconds of idle time. Denial of Service attacks, distributed or not, are mitigated by the Amazon ELB technology. Building Energy takes a proactive approach to mitigating application security risks when it develops software. For example, the following site details the top 10 risks encountered by the Open Web Application Security Project: (https://www.owasp.org/index.php/top_10_2013-top_10). When designing, coding, testing, reviewing, and deploying the application, Building Energy is always making sure that these common risks are not introduced into its system. All changes to the implementation, configuration, and deployment of the system are always reviewed by at least two other developers before being committed. Finally the Building Energy user system is configured to be secure against users leaving their computers unattended and over-the-shoulder attacks. Users are logged out after 15 minutes automatically, and passwords have a minimum complexity requirement. And after 3 failed login attempts, the user account is locked to prevent brute-force password attacks. Conclusion Building Energy uses advanced, industry standard security practices to ensure complete security of customer data, compliance with regulations, and that customer data is valid and 7

uncorrupted. By taking an approach of minimal exposure and layering security access controls according to risk and value, Building Energy can assure its customers that their data are safe. 8