Defense Department Contractors Targeted

In the last week Lockheed Martin, then L-3 Communications Holdings have been in the news due to sophisticated cyber attacks on their networks by unknown actors. Now there are rumors that Northrop Grumman may have been targeted as well, since the company shut down remote access to the company's network. Are these events linked to the attack on RSA which was reported on May 17th?

For those that haven't been keeping up, it is assumed the adversaries responsible for the RSA intrusion may have access to the seed files, serial numbers and the algorithm for multiple RSA keyfobs used by over 40 million RSA customers worldwide. Although RSA is saying that this information alone can't be used to launch an attack, it's not hard to assume that the attackers either already have or are confident they can get what they needed to use the stolen RSA information to launch a successful attack.

This recent activity goes beyond the need for "cleanup on isle 9", and leads one to believe that all these events could be the start to a series of attacks which were extensively planned, beginning with the RSA attack, and are now and will continue to be well resourced. Given the high profile nature of the businesses being targeted, and the level of effort involved, I think it's safe to assume that we will see more from these attackers in the future. In an effort to better prepare ourselves for future attacks here are some questions needing answers:

1. What data were the attackers after and why?
2. How did those companies get exploited?
3. Were there signs prior to the exploitation attempts?
4. Was there active reconnaissance of the company or their users?
5. Were there exploitation attempts against their users that failed?
6. Were there exploitation attempts against the company network?
7. Is the RSA attack and these incidents truly linked?

VPN access, albeit a necessity for remote users, is a major security risk that needs to be actively monitored. One of the initial steps in conducting network defense is to define the enclave’s borders which is increasingly difficult because of the needs of remote users and the federations across organizations. Each access point of a network needs to be heavily monitored and the systems that are used to access the VPN need to be examined on a regular basis to ensure there is no malicious software located on their systems. Given the current trend to move to the cloud one begins to wonder where the enterprise starts and stops and how we can truly protect the enterprise from the perimeter.

Reference:

http://www.eweek.com/c/a/Security/Northrop-Grumman-L3-Communications-Hacked-via-Cloned-RSA-SecurID-Tokens-841662/

http://www.informationweek.com/news/government/security/229700151

http://www.lockheedmartin.com/news/press_releases/2011/0528hq-secuirty.html

RSA Hacked by Advanced Persistent Threat (APT)

In the wake of the most highly coveted cyber security conference in the world - The RSA Conference, RSA has reported that they have been the victim to a highly sophisticated cyber attack. RSA, the world's leader in security products and solutions, utilized by countless customers worldwide to secure their business operations, stated in a open letter to customers that it had been infiltrated by a Advanced Persistent Threat (APT). Letter by Art Coviello, Executive Chairman.

APT's are highly skilled individuals who target the victim in various means in highly sophisticated mannerisms and have possible links to nation states. These actors attempt to gain access to the data inside the organization without being detected, presumably for the purpose of intelligence collection and potentially establishing a foothold within the network for destructive or deceptive operations.

The letter states that certain information was extracted from RSA's secure network and that some of the information was specifically related to RSA's SecurID two-factor authentication products. While the letter does state that RSA believes that the information extracted does not enable a successful direct attack on any RSA SecurID customers, the letter did not elaborate on the risk of information stolen which was not related to RSA's SecurID products.

SecurID is a two-factor authentication product allowing more robust authentication's through a requirement for something you know to be added to something you have. In this case your username and password is something you know, while the code provided on the display of your SecurID is something you have. With SecurID an attacker could obtain your username and password but still would not be able to gain access to the system as they would not have the rotating code displayed on the SecurID which is in your possession. If there was a way for the attacker to know the rotating code without having possession, it would pose a significant risk to the mission-critical data and applications that leverage SecurID.

RSA is confident that the information stolen alone does not enable a successful direct attack on any of their RSA SecurID customers. They do go on to state that this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. Reading between the lines, are they saying that this information makes SecurID ineffective without compromising username and password? If so, I think it's safe to assume that without the protection of SecurID, hundreds or thousands of companies and government agencies could be vulnerable to attack.

Creating New NIEM Services with Policy Based Integration & Governance

Problems with NIEM Enablement

There are several barriers to adoption of NIEM that must be dealt with. The first is that Data is currently represented in terms that the enterprise has defined and semantics likely differ between NIEM and the currently leveraged legacy data formats. Second, requirements for run-time security and governance of new NIEM-enabled services adds new complexities to which the current enterprise may not be accustomed to.

Database and Legacy Application Integration

Our philosophy is to allow for data integration through a logical model, which provides a necessary level of abstraction to achieve data decoupling and lifecycle management. A critical requirement of NIEM is to allow for integration and mediations between multiple back-end legacy data structures, and formats thus, it is critical that customers be provided the capability to import legacy data models, and file formats and translate them into the NIEM schema so they can carry out their information sharing needs.

Layer 7 Value: Layer 7 provides the capability to import models in standard formats, and enrich data integrations with rules, and mapping to produce NIEM-enabled services without writing a single line of code. With Layer 7, data integrations may be accomplished with a click of the mouse, and at run-time the Layer 7 appliance can transform and validate data before it is submitted to the connected legacy applications and services. The distributed deployment model improves performance and scalability relative to hub and spoke architectures. All data services use standard interfaces for incorporation into any business process or target application, and can be adapted to meet changing requirements over time.

NIEM Services Governance

NIEM as a framework is designed to fulfill the following four primary goals; to determine information sharing requirements, to develop standards, and vocabularies to meet these requirements, to provide technical tools to support development, discovery, dissemination and reuse, and to provide training, technical assistance, and implementation support.

Layer 7 Value: Through use of Layer 7’s policy governance products, run-time frameworks may be used between consumers and services to enforce and apply NIEM requirements in a highly configurable, centrally managed, and dynamically updatable fashion while still maintaining the desired ability to meet the goals of just-in-time integration, flexible system design by loose-coupling between software components and reuse of software components across diverse business processes. Examples of governance requirements met with Layer 7 include:

• Threat Protection - While numerous cyber defense point solutions exist – crypto devices, firewalls, identity and access management systems that encompass biometrics, smart cards, audit software, etc. – they tend to be narrowly deployed and narrowly focused (i.e., by office, department or bureau), rather than integrated to form a government-wide or even a nation-wide security barrier. SOA and cloud security solutions, on the other hand, are designed to deal with the elimination of boundaries between systems and the ever-growing use of shared and common resources. As NIEM-based services are exposed outside of the enterprise it is critical that we look to not only traditional defense in depth concepts to enhance our security posture of these new services but further look to the new risks that we are exposing to our enterprise, and our legacy business systems. The Layer 7 product delivers inherent cyber defense capabilities to address common threats associated with SOA, Web Services, and Cloud implementations. It acts as a Policy Enforcement Point (PEP) which proxies and inspects every message destined for and/or returned from a Firewall-protected service, based on a user-defined set of policies. Policies can incorporate any combination of identity, authentication protocol, time of day, IP address, message count, message content or routing parameters. In addition, through Layer 7 robust audit and logging services can be created which audit usage and misusage of each NIEM service.
• Access Control - With NIEM we require that newly created, and available services have access control applied, and reapplied as policies for access's change. In addition, supporting multiple credentials and authentication techniques is highly desired so that a single NIEM application can authenticate users from various agencies and authorize them using a common policy. The Layer 7 SecureSpan and CloudSpan product lines provide wide support for XACML, allowing it to be used directly within the appliance as an authorization policy language, or indirectly by supporting integration to third-party XACML-compliant enterprise products. Not only does this allow for high speed, XACML-based policy decision within the Layer 7 appliance for in-line authorizations as part of a PEP, but it additionally allows Layer 7 to be utilized as a central Policy Decision Point (PDP). If your agency doesn't have a externally available attribute service - Layer 7 can help. Layer 7 provides Attribute Service capabilities within its XML Gateway products, delivering support for X.509 Attribute Sharing Profile, as well as Homeland Security Presidential Directive (HSPD) – 12 Backend Attribute Exchange (BAE). Not only can Layer 7 provide support for building Attribute Services based on the leading standards, but it can also provide policy-based security for authentication, authorization, digital signing, and encryption to meet the highest security requirements for attribute dissemination.
• Identity Federation - Sharing application data and functionality over the network to external divisions and partners requires trust between two applications in different identity domains. Establishing this trust in user-machine interactions is challenging, and harder still in machine-to-machine SOA and cloud environments. As NIEM aims to support federation across its user-base, this too is a requirement of the service governance layer and luckily is a capability that Layer 7 provides. Layer 7 is the only XML security vendor to offer enterprises a solution for managing Web services federation from client application to Web service without programming as well as a provide a built-in SAML based Secure Token Service. The Layer 7 Web service federation solution can integrate with leading identity management, federation and security token services. The Layer 7 SecureSpan XML Firewall and The SecureSpan XML Networking Gateway also provide customers a flexible SAML based Security Token Service (STS) appliance for consuming, validating, creating and transforming security tokens including Kerberos, SAML 1.1 and 2.0. Likewise the SecureSpan XML VPN Client provides a admin-configurable tool for establishing PKI based trust on a client application, managing token requests from an STS (3rd party of Layer 7), and packaging a token into a secure SOAP call. Layer 7’s SecureSpan XML VPN automatically manages token negotiation using standards like WS-Trust, WS-Federation, and packaging of SOAP calls on the client application using WS-Security and WS-I Basic Security Profile to name some standards. All this is accomplished with zero upfront code and no down-time for policy updates.
• Monitoring - As SOA adoption has matured, new services have come online and been offered throughout the government enterprise, crossing organizational, network, and even classification boundaries. These newly formed IT Communities of Interest (IT COI) require a shared knowledge of their individual and collective purpose, mission objectives, service level agreements, security, etc., but also–critically–require a common interpretation of dependencies should one or more of the services go down. Today, services within one government organization are generally well constructed, secured and monitored to ensure availability. However, current monitoring solutions provide little to no service availability information for external members of an IT COI. As such, should a firewall go down at the boundary of a service provider’s domain, external entities may no longer be able to reach a service even though the service provider will still register it as being available. A new type of federated monitoring solution is required to solve this availability vs. “reach-ability” problem – one that monitors service characteristics not only within its own domain, but also from the service provider's network perimeter. Such a solution would allow external users to accurately measure a service’s availability, reach-ability and performance. A number of standards already exist for this purpose, including WS-Management and Web Services Distributed Management (WSDM) for metric collection, as well as WS-Notification or WS-Eventing which can be used for metric publishing/ subscription. In fact, the Department of Defense (DoD) and Intelligence Community (IC) have developed the Joint DoD/IC Enterprise Service Monitoring (JESM) specification, which is based on a subset of WSDM and WS-Eventing functionality.

Conclusion

Through Layer 7 Data and Services Governance, a common NIEM-supported data model may be created, and constantly managed through change management data lifecycle governance. In addition, Layer 7 incorporates a services governance layer onto the newly created data services to allow for NIEM-supportive Web Services to be provided securely across the enterprise, and with external partners.