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.

WikiLeaks–How to Fix a Leak with Better Plumbing

The 9/11 Commission Report cited "pervasive problems of managing and sharing information across a large and unwieldy government that had been built in a different era to confront different dangers". Since 9/11 governments around the world have considerably adjusted their stance on information-sharing to allow more adequate and timely sharing of information. Unfortunately, the need to share information quickly in many situations had priority over the need to protect it and this left security policies, certification and accreditation practices, and existing security controls behind.

WikiLeaks may jeopardize all we've worked towards to enhance information sharing, and impede pursuits to make information-sharing more effective. Or it may serve as a wakeup call that our current policies, processes and solutions are not adequate in today's world where information must be collected, fused, discovered, shared and protected at network speed.

Here at Layer 7, we've been working with government agencies worldwide to support their needs for sharing information more quickly, while introducing a more robust set of access and security controls to allow only those with need-to-know clearance access to privileged information. In the following paragraphs, I'm going to discuss how Layer 7 Technologies aids in breaking down information-sharing silos while maintaining a high degree of information protection, control and tracking.

There are multiple efforts underway across government agencies to use digital policy to control who gets access to what information when, as opposed to relying on a written policy. Layer 7's policy-oriented controls allow for digital policy to be defined and enforced across distributed information silos. Either inside an enterprise or in the cloud, using Layer 7,government agencies and commercial entities can define and enforce rules for information discovery, retrieval and dissemination across a variety of security realms and boundaries. With the right kind of policy controls, companies can avoid a WikiLeak of their own.

Layer 7 provides information plumbing for the new IT reality. Using Layer 7 products organizations can ensure:

Data Exfiltration –The WikiLeaks scandal broke because of a single user’s ability to discover, collect and exfiltrate massive quantities of information, much of which was not needed for the day-to-day activities of the user. With Layer 7, digital policies can be defined and enforced which put limits on the number of times a single user can retrieve a single type of data or multiple types of data that, when aggregated together, could be interpreted as having malicious intent. If the user goes beyond his administratively imposed limit, Layer 7 can either allow the operation while notifying administrative or security personnel of the potential issue, or can disallow access altogether while awaiting remediation.

Access Control -The heart of any information system is its ability to grant access to people who meet the "need to know" requirement for accessing the information contained within. The reality with government organizations is that many information systems rely on the user’s level of clearance, the network he is using, or course-grained information likethe branch of service he belongs to, in order to grant or deny access to an information-sharing system in its entirety. For those going beyond the norm with usage of Role Based Access Control (RBAC), the burden of administrating hundreds or thousands users, based on groups, is formidable and limits the effectiveness of the system; it increases the likelihood that the system has authorized users whom no longer have “need to know” of the information.

Layer 7 policy enforcement and decision allows for user authorization through either Attribute Based Access Control (ABAC) or Policy Based Access Control (PBAC). These types of authorizations correlate through policy, attributes about the user, resource and environment in order to allow/deny access. Attributes can be collected from local identity repositories or from enterprise attribute services.

In addition, enterprise attribute services can be federated to allow for attributes to be shared across organizations, thereby minimizing the requirement of having to manage attributes about users from other organizations. An often-overlooked factor of authorization is the need to tie typical authorization policy languages like XACML (is user X allowed to access resource Y) to policies around data exfiltration, data sanitization and transformation, and audit. This is the area where Layer 7 stands out: not only do we have the ability to authorize the user, but we can also enforce a wide variety of policy controls that are integrated with access control.

The following blog posts by Anil John, a colleague whom has specialization in the identity space, provides good information about the benefits and needs of the community in moving from roles to policy and attributes. Policy Based Access Control (PBAC) and Federated Attribute Services

Monitoring, Visibility & Tracking - Even when controls are in place that help mitigate the issue of “need to know,” there will always be a risk of authorized users collecting information within the norms of their current job and role. In support of this, visibility of usage by the individual IT system owner and across enterprise systems is key to limiting this type of event in the future. Layer 7 allows for federation of monitoring data so information about data accesses can be shared with those organizations monitoring the network or enterprise. This allows authentication attempts and valid authorizations to be tracked, and distributed data retrieval trends analyzed on a per user basis across the extended enterprise.

Leakage of privileged information to unauthorized users can never be 100% guaranteed. However, with the simple implementation of a policy-based information control like Layer 7, access to confidential information can be restrictedand tracked.

Creating Robust Net-Centric Services through Policy

Next Tuesday at TMForum Management World Americas conference in Orlando, I'll be presenting along with Sriram Chakrapani, (Chief, Integration Engineering Division, DISA) a presentation titled Policy Enabled Net-Centric Information Sharing. Due to this, and a whitepaper I'm putting the final touches on titled "Robust Net-Centric Services", I thought it would be an opportune time to write a post discussing the value of policy in defining robust net-centric services.

As integration frameworks, Web Services and Restful applications adequately address how applications get exposed and communicate via SOAP/XML to exchange information with one another in a platform agnostic way. In real-world applications however, security, reliability, routing, bandwidth conservation, versioning and other requirements still have to be dealt with and in turn severely impact the loosely coupled nature of net-centric services.

For tactical edge deployments as well as disadvantaged (in one way or another) enterprise deployments these requirements are vital as web services and consumers undergo challenges and need to operate in a constantly changing environment. Bandwidth and connection state among other things require web services to have situational awareness where they can adapt to a constantly changing scenario. A simple example of such a change could be that a consumer and service are in use in a connected state to DISA Net-Centric Enterprise Services (NCES) and then become disconnected due to a kinetic or cyber attack. In this disconnected state the information exchange must continue to operate seamlessly by moving to a fall-back set of requirements (security, transport, reliability, etc.), locally deployed core enterprise services (machine to machine messaging), and potentially a cached business service. All without impacting the user.

The presentation and paper proposes the concept of “Robust Net-Centric Services” or “net-centric services with a high degree of resilience even when faced with a comprehensive array of faults and/or challenges and inherently capable of reacting gracefully to both internal application changes as well as external environmental changes, all without impacting information exchange”.

Given the distributed and federated nature of robust net-centric services, especially those supporting tactical edge communications; the ability to define robust requirements using policies, which are understandable and interoperable across a variety of implementations while at the same time implemented in a distributed fashion and subsequently easily changed is key to achieving complete information superiority.

The paper and presentation will highlight the four primary challenges to creating robustness. For the sake of brevity, I'm only going to list the four categories in this blog post. Each will be detailed in the paper when it is released.

1. The availability and robustness of a network
2. The availability of resources to execute a particular function
3. Information Assurance (IA)
4. User Interface (UI)

In order to accommodate the challenges above, it is required that we look back to the fundamental principles of software engineering: flexible systems are achieved by decoupling the variable parts of the implementation from the invariant parts. This variable layer can then be managed without affecting the system invariants. In this, conflicting constraints and capabilities can be reconciled, managed and constantly monitored. For example, performance and response time requirements can be weighed against security, confidentiality and privacy requirements.

Robust Net-centric services employ a deployed policy-driven and intelligent run-time capability to provide a Policy Layer, so that applications can be built based on their perspective business requirements, allowing applications to be deployed without knowledge of requirements they might face during certification, deployment, or during operation.

The Policy Layer provides a light-weight federated on-ramp to the enterprise and to the particular enterprise services in which the application depends upon, and facilitates a policy oriented approach to connectivity, and integration to locally deployed resources as well as those available on the enterprise network. This layer architecturally is made up of two fundamental concepts a Policy Enforcement Point (PEP) and a Policy Application Point (PAP). The following diagram illustrates how policy and a run-time policy enforcement and application capability could be deployed to allow for robustness in the face of a comprehensive array of requirements, and or situational challenges.

Through Policy enablement, operators can create and modify integration, caching, access control, privacy, confidentiality, audit logging and other such policies around the business services, without interfering with the development of the services themselves. This is the first step towards real-world implementation of loosely coupled SOA and a necessary step in preparation for robustness.

Email me if you would like to receive the paper on robust net-centric services when it is completed or if you have unique challenges/situations that you would like to see conveyed in the paper. If you would like to learn more about how Layer 7 products support the vision of robust net-centric services today, contact your local sales government representative. I hope to see some of you in Orlando!

Hacking as a Service (HaaS)

On Monday this week there was a very interesting post by Andy Greenberg a blog writer for Forbes.com which introduces a botnet herd standing by for payment and targeting instructions to launch a powerful Distributed Denial of Service (DDoS) attack. It appears based on his research that the botherd called "I'm DDOS" and available at "IMDDOS.org" is supposed to be used for testing purposes, however it is not clear how any type of target validation would or could be done by the company running the service to validate the target belongs to the attacker. You can see from the User Interface (UI) that the service looks to be fairly easy to use making it a likely attack tool for anyone with minimal computer skills and a grudge.

As with pioneers in computer infrastructure as a service, such as Salesforce and Amazon’s EC2 cloud, cyber arms dealers have begun asking customers, “Why buy when you can rent?” Renting cyber attack capabilities allows a political activist, terrorist group, or nation state to launch an attack on an online application - on demand. Those familiar with Cloud Computing and Software as a Service should recognize this as being the malicious equivalent - "hacking as a service".

This is interesting timing as I recently gave a breakfast panel presentation where I talked about the problem of "good vs. evil" in development of new capabilities characterized as Cloud computing. I see this as just another example of the new breed of cyber capabilities we will see in these times of on-demand computing.

I also highlighted a DEFCON 18 presentation which did a proof of concept to show a cloud-based Distributed Denial of Service (DDoS) capability.

It is clear that the "?? as a Service" model is going to be popular for people wanting to bring their products to market quickly and for those that want to see results with minimal up front capital costs.

Letter to the President on Cyber Security

The United States Senate sent President Obama a letter on July 1st. The letter spoke of the criticality of securing our nation's information systems, communications networks, and critical infrastructure, and states that there is an urgent need for action to address the vulnerabilities. Action in the text is largely comprised of policy, and coordination, however it does state the need to improve and expand the U.S. cyber workforce and increase cyber threat awareness throughout the country.

This letter is a prelude to a number of highly sensitive pieces of legislation that the President will need to comment on in the coming weeks and months and likely means that Senate thinks that there may be opposition to their legislation.

Here is the link:
http://www.nationaljournal.com/congressdaily/issues/documents/Letter_President_on_Cyber_Security_Legislation_070110.pdf