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

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.

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 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.

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.

Although I was stuck in DC, I read online that he spoke of Partnership and Transparency as being critical components in the President's Cyberspace Policy Review. Mr. Schmidt also announced that the Obama Administration had revised the classification guidance for the Comprehensive National Cybersecurity Initiative (CNCI) and that the unclassified portion would be made available by the end of day on Tuesday on the whitehouse.gov website. CNCI was launched by President Bush in National Security Presidential Directive 54/Homeland Security Presidential Directive 23 (NSPD-54/HSPD-23 ) in January 2008. Although I'm excited about the potential of Partnership and Transparency as I too believe we can not be successful in cyber space without them, I was more interested in the public release of CNCI, which illustrates some direction for our government in the shorter term.

Announcement of a funded strategy, even if it's not the Administrations promised National U.S. Cybersecurity strategy, couldn't have come at a better time. With the recent CNN broadcast, and the successful attacks in the last few months on Google, and Twitter, consensus is that the US is not ready for a sophisticated cyber attack that crosses Government, critical infrastructure, and private domains.

If you watched the CNN special, you would have seen that the question wasn't whether we could defend ourselves from a nation state or hacker group or launch an attack across cyber space, but rather could we act quickly enough to an attack while being impeded by questions of law, policy, politics, and jurisdictional boundary - issues not shared with our fast moving, highly sophisticated adversaries.

CNCI has the following major goals:

• To establish a front line of defense against today's immediate threats
• To defend against the full spectrum of threats
• To strengthen the future cybersecurity environment

Layer 7 Technologies a Vendor of dynamic cyber defense products, provides our customers with the ability to protect applications, enable application monitoring for situational awareness, and the ability to adapt in the face of attack. These capabilities are critical in providing solutions across all three of the major goals of CNCI.

For more information on CNCI, please see www.whitehouse.gov

For more information on Layer 7 Technologies, please see www.layer7tech.com

Identities for cloud computing can be broken down into the following categories:

• Enterprise - Enterprise Users, and applications that will access cloud applications
• Internet - Customers, Partners, and Unanticipated Users that will access cloud applications
• Cloud - Cloud applications that will access cloud, enterprise, and partner applications

Whether we are talking about cloud usage, or cloud administration, identities can be binned into one of these three categories. The following paragraphs focus on the options and challenges in implementing an identity and access control architecture for cloud computing.

Identity Management - Identities may be associated with human resources hiring and firing, new or changing partner and contractor relationships, or new servers or applications being setup. Processes may include identity creation and role/group addition, credential issuance, audit and compliance, and on-going management and eventual deletion. Most companies leverage products which govern the creation of identities within their enterprise in accordance with their particular compliance regulations.

There are two approaches to identity management in cloud computing:

• Leverage existing enterprise identity management system for cloud identities
• Utilize a new cloud based identity management system and process for cloud identities

User Experience

Manageability

Compliance and Risk

Cost

• Double the amount of work required to administer users
• Purchasing and fielding identity products to the cloud may be costly
• Separate Audit and Compliance may requires significant investments