CJ Michael – RISC Management and Consulting

heartbleed_bug The big news in internet security right now is the Heartbleed Bug. Announced this week, it affects OpenSSL versions 1.0.1 through 1.0.1f and 1.0.2-beta. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the site. A successful intruder could obtain your private information from an affected site and impersonate that site until its operators catch on. Since the bug has been in the wild since OpenSSL released version 1.0.1 in March 2012, it is likely that your organization is vulnerable along with many of the sites you frequent throughout the day.

To address this issue in your organization, you need to create an inventory of any web servers and certs using OpenSSL version 1.0.1 and 1.0.2-beta. Once you have that inventory, you can patch affected sites by upgrading to OpenSSL 1.0.1g, released April 7, 2014. Users unable to immediately upgrade can alternatively recompile OpenSSL with the handshake removed from the code by compile time option -DOPENSSL_NO_HEARTBEATS. Version 1.0.2 will be fixed in 1.0.2-beta2. Link: https://www.openssl.org/source/

Then All User populations that logged in via that site have to change their passwords, and any other encrypted sensitive information that got transmitted across that server, with OpenSSL, must be addressed. This might be notification, changing of account numbers, or that no reasonable action can be taken.

A Web based test to see if your server is vulnerable is here: http://filippo.io/Heartbleed/

There is a test utility/proof of concept available here: https://gist.githubusercontent.com/sh1n0b1/10100394/raw/4f24ff250124a03ad2d3d6010b6402c3a483d2f3/ssltest.py

Snort signatures to look for malicious Heartbleed activity can be found here: http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/

As a consumer, keep an eye open for popular websites updating their security practices and change your passwords once the bug has been fixed.

This recent announcement is just another reminder to be vigilant with your organization’s data and your personal information.

For more information or to inquire about RISC Management’s Risk Mitigation services, visit our website at www.RISCsecurity.com.

by CJ Michael

One of the most difficult systems to manage is change. Every organization undergoes change in their applications or operating environment; it is difficult to stay relevant in your industry without keeping up-to-date. One of the most convincing reasons to implement a formal process to document and approve changes is that it really only takes one oversight to create chaos in your organization and unintentionally expose information security problems.

Change control can be defined as “a formal process used to ensure that changes to an application or system are conducted in a systematic, controlled, and coordinated manner.”¹ The benefits of having a system for implementing changes in the organization are numerous and include reducing unauthorized changes and/or downtime, improving communication, maintaining system integrity, and preventing unnecessary security exposures. These benefits can translate into better sales, improved margins, and a more productive workforce. In determining the processes to follow for tracking and approving changes, an organization-wide decision must be made with risk management in mind. Consider any current processes in place and their effectiveness or what change tracking system is most compatible with existing infrastructure. Remember that the goal of a project like this is to improve processes, not make them more difficult or complex!

Change control is a “standard method and set of procedures for handling changes within the IT environment to help minimize risk to the business” and is a part of the more comprehensive discipline of change management. When employing a change management system, your organization should consider including all or most of the following steps for effective change management. This is a pattern recommended by Michelle Bigelow, contributor to Implementing Information Security in Healthcare: Building a Security Program.

A change is requested
The change is reviewed
The change is either approved for testing or denied
An approved change request is tested
The change is documented
The change is scheduled
Information about the change is communicated to all affected parties
The change is implemented
The change is evaluated
Technical vulnerabilities are assessed
The change control database is updated

This is a very high-level process for managing changes within your organization. There are many other potential steps that are necessary depending on the importance of the system or regularity of the changes or updates. Unfortunately for many organizations, a lack of controls and documentation around change management is adding to risk exposure on a daily basis. If this type of program is something that your organization needs, please contact RISC Management for assistance. Remember that with any security program decision, the first step is always a Risk Analysis. If you don’t identify, analyze, and document your risk, you’ll never effectively manage it.

Sponsored by: RISC Management, www.RISCsecurity.com

References

Implementing Information Security in Healthcare: Building a Security Program