Tuesday
Dec312013

Building a Cloud Security Framework - Helping a Utility Securely Migrate to the Cloud

Note: This blog post orginally appeared on the SecureState blog.

Through regular discussions with a client in the utilities industry, the director of security at a large utilities provider approached SecureState with a problem.  The CIO had decided to move a number of the company’s core applications to the cloud and needed their security requirements for this project within two weeks.  The utility already had security requirements in place for traditional third-party vendors; however, these requirements were not a good fit for the cloud services the company was looking to adopt.

Unlike traditional third-party solutions where the vendor is responsible for all or most of the security controls in the cloud, there are often cases where the client is responsible for managing and maintaining key security controls.  For example, if a company was hosting a home grown application at a PaaS (Platform as a Service) provider, the client would generally be responsible for the security of the application itself.  The cloud provider of the PaaS would be responsible for the securing the platform and infrastructure supporting the application.  It is critical to clearly outline who is responsible for which component and have requirements which provide the desired level of security while being flexible enough fit these different service models.

Cloud Security Framework

Building a Framework:

To assist with this, SecureState created a program to review, approve and manage these cloud providers.  The program was built around a SecureState developed Cloud Security Framework (CSF). To develop this framework SecureState met with stakeholders to gather business, technical and security requirements.  SecureState also looked at the regulatory requirements related to the data that would be stored and processed by cloud providers.  The framework leveraged the utilities company’s existing security policies, procedures and standards while adding additional requirements specific to cloud computing environments.  To ensure the requirements were flexible enough to apply to the various cloud models and use cases the requirements were broken down by the type of cloud service used and the classification of the data processed and/or stored by the provider.

Once the framework was completed SecureState met with executives at the organization to review the CSF.  During this meeting we conveyed the importance of the framework to the business and outlined how the company should align to the new framework.  Once we received executive management buy-in, the framework was adopted for use by all lines of business moving services to the cloud, not just IT.  This provided the company with a unified approach to managing the security of cloud services, thus ensuring all corporate data moved to the cloud was appropriately secured.

Managing the Security of Cloud Services:

The director of security also needed to develop processes to prioritize, review and track which cloud services where approved for use.

The utilities company also needed a program to manage and track what data was being stored and/or processed by these cloud services.  Without a robust program in place the security department would quickly lose control of where their sensitive data was stored and which vendor had been approved or denied. So, SecureState used our vendor management solution methodology to develop a program to review, approve and manage the cloud service providers.  This solution allowed the client to enter requests to have potential cloud service providers reviewed.  Once a provider is entered for review, a questionnaire is generated based on the type of cloud service used and the data stored and/or processed by that provider.  This questionnaire is then sent to the point of contact at the cloud service provider to gather information on what security controls are present in their environment.  Once the questionnaire is complete, SecureState works with the cloud service provider and client to snap the cloud service into the CSF.  To ensure the lines of responsibility were clearly defined, each requirement in the CSF was assigned to either the cloud security provider or client. During this review process SecureState would enumerate risks posed by the proposed solution and outline where the solution did not meet the CSF. Using this information, the utility’s security group could determine if the new solution posed an acceptable level of risk, if the solution would be rejected or if require additional controls needed to be added to the design.

Leveraging our diverse knowledge and existing technology, SecureState was able to quickly eliminate the client’s problem. This enabled the client to quickly respond to the needs of the business while minimizing the risks of moving core applications to a cloud environment.  The solution provided by SecureState not only allowed for cloud vendors to be quickly and easily reviewed, but also provided a program to manage cloud services used by the client to ensure corporate information stored in house or in the cloud is protected equally.

Friday
Oct042013

What Manufacturers Should Do to Build Secure Devices - Integrating security into the product development life cycle

Note: This blog post orginally appeared on the SecureState blog.

Recently the security of network-enabled medical devices has earned a lot more attention as a result of new FDA draft guidance.

The Challenge:

The challenge now facing the medical device industry is how to secure these devices and protect against future attacks. Simply bolting new security features onto a product rarely works well, and changes at the end of product development are often expensive. Also, depending on the changes, it could mean recertifying the device.

Medical devices have some unique challenges here because security needs to be incorporated into both the hardware and software components of the device. Although a lot of research and work has been released on integrating security into the software development life cycle, very little work has been done on how to integrate security into hardware development.

There are number of different product development life cycles used to design and develop medical devices. At a high level all product development follows roughly the same steps of specification, design, development, testing, manufacturing and delivery.

Breaking the Flow – Adding Security into Product Development:

The proper way to address this problem is to integrate security into the product development life cycle.

+  Specification - During the Specification Phase the concept for the product and specifications are developed. During this stage, threat modeling should be performed to determine what types of threats are likely to attack the devices. Most manufactures do not have staff trained on how to perform threat modeling; therefore, it is recommended a third party such as SecureState perform this. Then security requirements should be based off of the threat modeling and regulatory demands the device must meet. These security requirements must be included in the overall device specifications.

+  Design - During the Design Phase the engineers take the product specifications and requirements defined above and use them to start designing the device.

Once the design is complete a security design and architecture review should be performed to make sure the design meets the security requirements established during the specification phase. This can be done using a third party like SecureState or another group inside your company, assuming they have the proper training and are separate from the team developing the new product.

If a proof of concept is created, penetration testing should be performed on the device to identify other attack vectors which may not have been thought of during the Specification Phase. It is important to note what security features have not been implemented, so time isn’t wasted testing items that have not yet been added.

+  Development - Often the Development Phase is split between hardware and software, although they may be intertwined.

In this blog I’ll be focusing on the hardware side, given the previous work already done on how to secure software development.

As the hardware is developed, security testing needs to occur as new features or functionality are added to ensure they do not introduce new vulnerabilities.

+  Testing - Once the device is developed, functional testing begins to verify the device meets specifications.

At this time, a final security review of the device should be performed. Once this occurs, a penetration test should be performed on the device to look for new vulnerabilities or weaknesses in the device.

+  Manufacturing - As the devices are manufactured, it is important to ensure the security specifications remain in place and new vulnerabilities are not introduced into the design.

During this phase, it is not unusual for small changes in the device to occur as final bugs are worked out. As these changes occur it is important to make sure they do not impact the security of the device.

+  Delivery - Documentation explaining the security features of the device, and how to implement them, needs to be provided to the customer. This is especially important when delivering devices to care providers who have to customize them for their environment.

+  Maintaining a Secure State – Securing the device does not stop once it is manufactured.

Although the steps performed above should help minimize the number and severity of bugs present in a device, it will not remove all vulnerabilities. Therefore a process needs to be created to address new vulnerabilities as they are discovered. This process should include creating patches when able and educating clients on how to mitigate risks posed by vulnerabilities.

Finally, devices should be penetration tested annually to identify new vulnerabilities.The practice of hardware hacking is advancing quickly. As new tools and attack techniques are developed, it is important to test new and existing devices against attacks.

Where to Begin:

As you can see, integrating security into product development is not an easy task. The difficult part is usually figuring out where to start.  If you already released a device or are about to release a new device, the best first step is to have a penetration test performed to determine how well it can resist attacks.

If you are about to start developing a new device, now is the time to engage SecureState to ensure you include security from the beginning.

In addition to the steps listed above, another key area to assist with developing secure products is training your engineers, developers and QA departments in security. Although this is a critical area it is outside the scope of this article. Until your staff is trained, the security assessments outlined above should be performed by a trusted third party such as SecureState.

Monday
Sep302013

The Cloud Problem – How Security Pros Can Migrate and Maintain Security

Note: This blog post orginally appeared on the SecureState blog.

More and more often, CIO’s and CSO’s are being tasked with moving their company’s core applications to the cloud. A headache for security professionals to say the least, and a challenge to quickly generate security requirements and ensure those requirements are followed.  Another problem that arises is that most companies already have existing security requirements in place for traditional third-party vendors, but these requirements are not a good fit for the cloud services being adopted.

Unlike traditional third-party solutions where the vendor is responsible for all or most of the security controls in the cloud, there are often cases where security professionals are responsible for managing and maintaining key security controls. 

For example, if a company is hosting a home grown application at a PaaS (Platform as a Service) provider, then the company’ would generally be responsible for the security of the application itself.  The cloud provider of the PaaS would be responsible for the securing the platform and infrastructure supporting the application.  It is critical to clearly outline who is responsible for which component and have requirements which provide the desired level of security while being flexible enough fit these different service models.

Start by Building a Framework:

To build cloud security, you first need to create a program to review, approve and manage cloud providers. This is something you can try to create on your own, or you can follow an example my company created.

To develop this framework start by meeting with stakeholders to gather business, technical and security requirements.  Then compare that with the regulatory requirements related to the data that would be stored and processed by cloud providers.  Once you do that you can leverage existing security policies, procedures and standards while adding additional requirements specific to cloud computing environments.  To ensure the requirements are flexible enough to apply to the various cloud models and use cases, the requirements should be broken down by the type of cloud service used and the classification of the data processed and/or stored by the provider.

Once the framework is complete meet with executives at your organization to review the Cloud Security Framework (CSF).  During this meeting convey the importance of the framework to the business and outline how the company should align to the new framework.  Once you receive executive management buy-in, the framework can be adopted for use by all lines of business moving services to the cloud, not just IT.  This will provide the company with a unified approach to managing the security of cloud services, thus ensuring all corporate data moved to the cloud is appropriately secured.

Managing the Security of Cloud Services:

In addition to creating a framework and earning corporate buy-in, security professionals also need to develop processes to prioritize, review and track which cloud services are approved for use.

Businesses also needed to manage and track what data is being stored and/or processed by these cloud services.  Without a robust program in place your security department will quickly lose control of where sensitive data is stored and which vendors are approved or denied.

The best way to tackle this problem is by coming up with a vendor management solution methodology to develop a program to review, approve and manage the cloud service providers.  Having this solution will allow security professionals to enter requests to have potential cloud service providers reviewed.  Once a provider is entered for review, a questionnaire can be generated based on the type of cloud service used and the data stored and/or processed by that provider.  This questionnaire should then be sent to the point of contact at the cloud service provider to gather information on what security controls are present in their environment.  Once the questionnaire is complete, CSO’s and CIO’s staff can work with the cloud service provider and their organization to snap the cloud service into the CSF.  To ensure the lines of responsibility were clearly defined, each requirement in the CSF should be assigned to either the cloud security provider or the business. During this review process you can enumerate risks posed by the proposed solution and outline where the solution did not meet the CSF. Using this information, your security group can determine if the new solution posed an acceptable level of risk, if the solution would be rejected or if it requires additional controls to be added to the design.

By leveraging the knowledge you gather, and using existing technology, as a security professional you are able to quickly respond to the needs of the business while minimizing the risks of moving core applications to a cloud environment.  This solution not only allows for cloud vendors to be quickly and easily reviewed, but also provides a program to manage cloud services used by the business to ensure corporate information stored in-house or in the cloud is protected equally.

Friday
Jun212013

Healthcare Interrupted - Top Five Vulnerabilities in Medical Devices

Note: This blog post orginally appeared on the SecureState blog.

As medical science advances, so too does the equipment used to deliver care. In a modern-day hospital, more and more medical devices, such as IV pumps, ventilators, MRI, CAT Scan and X-Ray machines are attached to hospital networks. Putting medical devices on the network provides a large number of benefits, such as supporting telemedicine and the easy transfer of test results to electronic medical records (ERM) systems. However, putting these devices on a network also introduces a number of risks.
Networked Cat Scan
By performing penetration tests on hospital networks and medical devices, SecureState has found that many commonly used devices are insecure and can be easily compromised.

Top Five Vulnerabilities in Medical Devices

1.)  Denial of Service Vulnerabilities - Among the most serious weaknesses found in these devices are flaws which allow attackers to crash a device or cause it to disconnect from the network. These devices are often very delicate, so basic denial of service attacks can crash them. We’ve seen cases where a flood of traffic, which any modern day desktop or laptop could handle, crashed a medical device. A device susceptible to this form of attack may simply disconnect from the network or could stop functioning all together, interrupting the care being delivered to the patient. Denial of Service attacks can be an inconvenience in many other industries, but when we’re talking about the healthcare industry this could directly impact a patient’s health depending on how badly the medical device fails.

 2.)  Weak and Default Passwords - Medical devices commonly have weak passwords set on them or have built-in back door passwords which cannot be changed by the hospital managing the device. This means that attackers can easily guess the passwords used to protect the device and gain access. Vendor built-in default passwords pose a special challenge because these credentials often give attackers access to diagnostic and configuration information which can aid in more advanced attacks.

Networked Medical Device

3.)  Missing Security Patches - Medical devices running on Windows or Linux operating systems are often missing critical security patches. Medical devices are often not patched once they are deployed, and are commonly years behind on critical updates. Compounding this issue, many devices are still running Windows NT and Windows 2000, which are no longer supported by Microsoft and therefore no longer get security patches for new vulnerabilities. Often times these missing patches leave these devices vulnerable to computer viruses such as Conficker, which downloads additional malware like keystroke loggers to a device and traditionally adds infected systems to a botnet. Additionally these missing patches allow attackers to easily break into these devices using readily available tools such as Metasploit.

4.)  Unencrypted Management Traffic - Management interfaces used to remotely administer and sometimes operate the device are frequently unencrypted. Similarly when these devices send data to a central monitoring and ERM systems, this traffic is often not encrypted. This means that attackers who are monitoring the network can steal passwords used to log into the device, hijack connections and view and alter patient information sent to and from the device. This is of particular concern for devices using WiFi networks.

5.)  Web Application Vulnerabilities - A growing number of network attached medical devices have web interfaces used for status updates or remote management. Often times these interfaces are not securely coded and contain web vulnerabilities such as cross-site scripting (XSS) and SQL injection. These vulnerabilities vary in the type and complexity, but could allow an attacker to log into a device without providing a password. That person could then change settings on the device or access private information.

Many Risks and Insufficient Guidance

As you can see, these vulnerabilities pose a number of risks to patient care. Most concerning is that many of these devices can be taken offline, shutdown or infected with a virus when an attacker isn’t even targeting them. When SecureState has investigated infections of these devices, we often find the virus was accidentally introduced into the network. Also concerning is the idea of attackers targeting on one of these systems, using these common vulnerabilities to crash medical devices, change settings, and view and manipulate patient data.

Recently the FDA released draft guidance for hospitals and device manufactures to secure medical devices. Although this guidance is a good start, it is too high-level FDA Medical Device Securityto be truly useful and does not provide actionable information hospitals and device manufactures can use to improve security. As an example, the FDA guidance mentions encryption, but does not provide any guidance around selecting secure algorithms or performing key management, which are critical to properly implementing encryption. Additionally, the agency does not recommend types of security tests that should be performed on devices, which can be used to verify that implemented security controls are actually working.

 In a future series of blog posts on medical device security, SecureState will discuss these types of vulnerabilities in more depth and provide our recommendations on how medical device manufactures, hospitals and regulators should address them.

Friday
Mar082013

Minimum Requirements for a PCI-DSS Risk Assessment

Note: This blog post orginally appeared on the SecureState blog.

In information security, various regulations require a periodic risk assessment. The Payment Card Industry (PCI) Data Security Standard (DSS) is no exception. For PCI-DSS, the risk assessment process is designed to identify, analyze, and document risks to credit card data. The assessment is the integral component of the risk management strategy, and therefore should be used to manage threats and vulnerabilities, and document control effectiveness.

PCI-DSS Requirement 12.1.2 requires a “formal risk assessment” to be performed. However, what this means remained a topic of debate both among practitioners and those procuring their services. Auditors and their clients often grapple with compliance issues as they interpret the “gray” areas associated with compliance frameworks. In 2012 the PCI Security Council formed a Special Interest Group (SIG) to remove some ambiguity when executing risk assessments to meet PCI-DSS requirements. The output from the SIG was the Information Supplement: PCI DSS Risk Assessment Guidelines V1 document.

Industry adoption of the guidance provides consistency and helps manage merchant expectations, but more importantly should entice entities who store, process, or transmit cardholder data (CHD) to evaluate their processes and reduce their risk posture consistently. This manifests itself in benefits for the brands (e.g., VISA, MC, AmEx), the merchants, and ultimately their customers.

PCI Web Seminar Registration

Before we dive into the guidance provided in the Information Supplement, it is important to note that the SIG made it clear the risk assessment is used to determine what additional controls are needed to protect CHD and cannot be used to avoid or bypass any PCI DSS requirements.

The Information Supplement lists a variety of risk frameworks (OCTAVE, ISO 27005, NIST SP 800-30) but does not require a specific framework to be used. Any risk framework can be used that meets the guidelines outlined in the document. Below is a summary of what is minimally required for a risk assessment to be PCI-DSS compliant. There are other items that should be included in a risk assessment, but today we are just looking at the minimum requirements outlined in the SIG document.

  • Methodology must be defined and follow a documented process
  • Must be performed annually
  • Must cover any people, processes or technology which could impact the security of the Cardholder Data Environment (CDE). This is not simply limited to the CDE and must include any people, processes or technologies which are involved in the storage, processing or transmission of CHD. This includes people, processes or technology not directly involved with the processing of CHD that could impact the security of the CDE.
  • Asset inventory (people, processes or technology) that covers all payment channels and includes any asset that directly or indirectly impacts the processing, storage, transmission or protection of CHD or the security of the CDE.
  • Must identify threats, vulnerabilities and controls that could impact the security of the card holder data
  • Can be quantitative, qualitative or a mix of both
  • Must include risks posed by outsourcing to third parties
  • Identify and score threats (capabilities, impacts, likelihood, etc.)
  • Identify organizational and technical vulnerabilities
  • Identify controls and the effectiveness of the controls
  • Output of the risk assessment provides a prioritized risk mitigation plan

If your organization needs to be PCI-DSS compliant, it is critical that the risk assessment methodology used meets these requirements.

Contact SecureState if you need help performing a risk assessment or are if you are unsure if your current risk assessment process meets PCI-DSS requirement.

You are also invited to attend an exclusive Web Seminar on Tuesday, March 26th at Noon (ET) featuring a discussion of the new PCI-DSS requirements.  CLICK HERE to visit the registration page.