Thursday, August 28, 2014

Architectural Security aspects of BGP/MPLS

The inherent benefits of the MPLS (Multi Protocol Label Switching), is gaining widespread use for providing IP VPN services. With the emerging trend of connected systems, a global enterprise today is well connected with their partners, with MPLS being the preferred choice. Border Gateway Routing Protocol (BGP) is used to interconnect such autonomous systems by exchanging the routing informaiton across such systems. The emergence of Multiprotocol Extension, and other variations of BGP Protocol, has furthered the choice of MPLS VPNs. On the same lines, the security concerns on using such a network is also on the rise. The specific demands of customers in terms of security is also emerging as they experience issues of data breaches and security incidents.

The objective of this blog is not to explain about the BGP / MPLS as such and instead let us examine how the BGP / MPLS addresses the typical security requirements in this blog. The following sections of this blog have been extracted from the RFC 4381 published by Internet Engineering Task Force (IETF) in 2006.


Address Space, Routing, and Traffic Separation

BGP/MPLS allows distinct IP VPNs to use the same address space, which can also be private address space. This is achieved by adding a 64-bit Route Distinguisher (RD) to each IPv4 route, making VPN-unique addresses also unique in the MPLS core. This "extended" address is also called a "VPN-IPv4 address". Thus, customers of a BGP/MPLS IP VPN service do not need to change their current addressing plan. The address space on the CE-PE link (including the peering PE address) is considered part of the VPN address space. Since address space can overlap between VPNs, the CE-PE link addresses can overlap between VPNs. For practical management considerations, SPs typically address CE-PE links from a global pool, maintaining uniqueness across the core.

On the data plane, traffic separation is achieved by the ingress PE pre-pending a VPN-specific label to the packets. The packets with the VPN labels are sent through the core to the egress PE, where the VPN label is used to select the egress VRF. Given the addressing, routing, and traffic separation across an BGP/ MPLS IP VPN core network, it can be assumed that this architecture offers in this respect the same security as a layer-2 VPN. It is not possible to intrude from a VPN or the core into another VPN unless this has been explicitly configured. If and when confidentiality is required, it can be achieved in BGP/ MPLS IP VPNs by overlaying encryption services over the network. However, encryption is not a standard service on BGP/MPLS IP VPNs.

Hiding of the BGP/MPLS IP VPN Core Infrastructure

Service providers and end-customers do not normally want their network topology revealed to the outside. This makes attacks more difficult to execute: If an attacker doesn't know the address of a victim, he can only guess the IP addresses to attack. Since most DoS attacks don't provide direct feedback to the attacker it would be difficult to attack the network. It has to be mentioned specifically that information hiding as such does not provide security. However, in the market this is a perceived requirement. 

With a known IP address, a potential attacker can launch a DoS attack more easily against that device. Therefore, the ideal is to not reveal any information about the internal network to the outside world. This applies to the customer network and the core. A number of additional security measures also have to be taken: most of all, extensive packet filtering. For security reasons, it is recommended for any core network to filter packets from the "outside" (Internet or connected VPNs) destined to the core infrastructure. This makes it very hard to attack the core, although some functionality such as pinging core routers will be lost. Traceroute across the core will still work, since it addresses a destination outside the core.

Being reachable from the Internet automatically exposes a customer network to additional security threats. Appropriate security mechanisms have to be deployed such as firewalls and intrusion detection systems. This is true for any Internet access, over MPLS or direct. A BGP/MPLS IP VPN network with no interconnections to the Internet has security equal to that of FR or ATM VPN networks. With an Internet access from the MPLS cloud, the service provider has to reveal at least one IP address (of the peering PE router) to the next provider, and thus to the outside world.

Resistance to Attacks

To attack an element of a BGP/MPLS IP VPN network, it is first necessary to know the address of the element. The addressing structure of the BGP/MPLS IP VPN core is hidden from the outside world. Thus, an attacker cannot know the IP address of any router in the core to attack. The attacker could guess addresses and send packets to these addresses. However, due to the address separation of MPLS each incoming packet will be treated as belonging to the address space of the customer. Thus, it is impossible to reach an internal router, even by guessing IP addresses.

In the case of a static route that points to an interface, the CE router doesn't need to know any IP addresses of the core network or even of the PE router. This has the disadvantage of needing a more extensive (static) configuration, but is the most secure option. In this case, it is also possible to configure packet filters on the PE interface to deny any packet to the PE interface. This protects the router and the whole core from attack. In all other cases, each CE router needs to know at least the router ID (RID, i.e., peer IP address) of the PE router in the core, and thus has a potential destination for an attack.

A potential attack could be to send an extensive number of routes, or to flood the PE router with routing updates. Both could lead to a DoS, however, not to unauthorised access. To reduce this risk, it is necessary to configure the routing protocol on the PE router to operate as securely as possible. This can be done in various ways: 

  • By accepting only routing protocol packets, and only from the CE router. The inbound ACL on each CE interface of the PE router should allow only routing protocol packets from the CE to the PE. 
  • By configuring MD5 authentication for routing protocols. This is available for BGP (RFC 2385 [6]), OSPF (RFC 2154 [4]), and RIP2 (RFC 2082 [3]), for example. 

This avoids packets being spoofed from other parts of the customer network than the CE router. It requires the service provider and customer to agree on a shared secret between all CE and PE routers. It is necessary to do this for all VPN customers. It is not sufficient to do this only for the customer with the highest security requirements.

It is theoretically possible to attack the routing protocol port to execute a DoS attack against the PE router. This in turn might have a negative impact on other VPNs on this PE router. For this reason, PE routers must be extremely well secured, especially on their interfaces to CE routers. ACLs must be configured to limit access only to the port(s) of the routing protocol, and only from the CE router.

Label Spoofing

Similar to IP spoofing attacks, where an attacker fakes the source IP address of a packet, it is also theoretically possible to spoof the label of an MPLS packet. For security reasons, a PE router should never accept a packet with a label from a CE router. RFC 3031 [9] specifies: "Therefore, when a labeled packet is received with an invalid incoming label, it MUST be discarded, UNLESS it is determined by some means that forwarding it unlabeled cannot cause any harm."

There remains the possibility to spoof the IP address of a packet being sent to the MPLS core. Since there is strict address separation within the PE router, and each VPN has its own VRF, this can only harm the VPN the spoofed packet originated from; that is, a VPN customer can attack only himself. MPLS doesn't add any security risk here. The Inter-AS and Carrier's Carrier cases are special cases, since on the interfaces between providers typically packets with labels are exchanged. See section 4 for an analysis of these architectures.


There are a number of precautionary measures outlined above that a service provider can use to tighten security of the core, but the security of the BGP/MPLS IP VPN architecture depends on the security of the service provider. If the service provider is not trusted, the only way to fully secure a VPN against attacks from the "inside" of the VPN service is to run IPsec on top, from the CE devices or beyond. This document discussed many aspects of BGP/MPLS IP VPN security. It has to be noted that the overall security of this architecture depends on all components and is determined by the security of the weakest part of the solution.

Sunday, August 24, 2014

Perspectives of Business Reference Model

We are all witnessing the steady progress of the Enterprise Architecture(EA) discipline and it is now well understood that the EA is not just about IT infrastructure and the Business Architecture(BA) forms an integral part of EA. Unlike in the past, when Business Architecture was used for the purpose of eliciting the requirements for the IT systems, BA is used to develop and describe the targe business model and work on a road map that will get the business towards the target. The Open Group, as part of its "World Class EA" series, has published a White Paper on the Buiness Reference with an objective of providing the need help to organizations in developing BA assets and plan for the future.


The Open Group has developed the Business Reference Model to facilitate description of a business model through the five perspectives. The following diagram provides an overview of the structure and content of the BRM:

Image Source: The Open Group's World Class EA: Business Reference Model white paper.


Environment Perspective:

The Environment perspective addresses the context within which an organization must operate. It describes the external factors, such as the competitors and customers for an organization, in addition to the pre-established strategy defined by the organization for market positioning. This perspective is intended to describe why an organization is motivated to undertake particular courses of action.

The goal of understanding the business environment is to provide a good contextual knowledge base that informs the creation of effective architectures in the Value Proposition, Operating Model, and Risk perspectives.

The business challenge is to gain and exploit insights into the market, competition, and customer base that allow the organization to position itself optimally (described through strategy).


Value Proposition Perspective:

The Value Proposition perspective describes the offering produced by the organization in terms of products, services, brand, and shareholder value. It creates a belief from the existing customer, prospective costumer, stakeholder, or other constituent groups within or outside the organization where the value will be experienced – usually in exchange for economic value or some form of compensation.

The goal of understanding the value proposition is that it defines the customer experience and sets shareholder expectations. The value proposition also provides a baseline set of needs that need to be fulfilled by the Operating Model perspective. 

The business challenge is to develop a value proposition that is able to attract a suitable customer base, fulfil the needs of the customer base effectively, and generate sufficient benefit to satisfy shareholder expectations. All this needs to be achieved in a way that is consistent with, and reinforces, brand image and brand values.


The Operating Model Perspective:

The Operating Model perspective describes the resources at the disposal of the organization that will be deployed to generate the value proposition. This perspective is intended to describe how an organization will be able to deliver on its value proposition. Capabilities are the core enablers to operate the business from the perspectives of people, process, technology, and information.

The goal of operating model design is to allow executives and planners to evaluate the business through a wide variety of lenses and viewpoints in order to identify desired and enhanced states of the organization.

The business challenge is to identify the correct alignment of resources that will deliver the necessary customer and shareholder experience. Typical trade-offs to evaluate when structuring capabilities include centralization versus federation, matrix organization structures versus vertical integration, core versus context analysis, and process alignment versus competency alignment. The results of these trade-offs will produce different levels of efficiency versus agility versus stakeholder experience across different areas of the business.

The Risk Perspective

The Risk perspective identifies the uncertainties that may surround an organization in its delivery of the value proposition. This perspective is intended to describe the threats that face an organization from within and without. Typically, organizations model their architecture around the known, repeatable aspects of business operations. However, within a complex and volatile environment, unforeseen circumstances frequently occur in ways that may be extremely damaging to the business.

The goal of risk analysis is to gain a full understanding of potential scenarios that may adversely impact the business and then to prepare appropriately to address those risks in the event that they occur.
The business challenge of risk modelling is to ensure that risks are adequately understood (it is a great challenge to test for completeness in an exercise of identifying unlikely or unforeseeable scenarios), the impact of risk is appropriately quantified (again, challenging to accurately determine when there is limited precedent), and the mitigation steps for risks are appropriate to the risk level (in many organizations, over-compensation for risk can be as damaging as under-compensation, as valuable business activities are curtailed due to risk concerns).


The Compliance Perspective

The Compliance perspective represents activities that the organization must carry out in order to assure that the value proposition is delivered using an acceptable standard of business practice. This perspective is intended to describe the constraints that prevent an organization from acting in negative, destructive, or inappropriate ways. In many cases, compliance can offer opportunities for organizations to differentiate, by being first to access new markets by being compliant with new legislation.

The Compliance perspective acts in a similar manner to the Environment perspective in that it influences across value proposition, operating model, and risk, constraining all activities of the business to be in compliance with standards of acceptability.

The goal of the compliance architecture is to adequately understand the compliance requirements that exist and to ensure that appropriate mechanisms are in place to ensure they are met.

The business challenge of compliance is to appropriately translate commercial, quality, ethical, legal, and regulatory constraints (which tend to be complex and open to interpretation) into a set of clear, unambiguous operational policies that can be followed consistently and at scale within a large organization. Interpretations that are too risk-seeking in nature will tend to generate compliance breaches, with associated financial and reputational penalties. Interpretations that are too risk-averse will tend to stifle business activities and reduce the ability of the business to change quickly to meet new environmental circumstances.


This blogs contains excerpts from the white paper "World Class EA: Business Reference Model" published by The Open Group and this white paper is available for download.

Sunday, July 20, 2014

A Checklist for Architecture & Design Review

Mostly the security requirements remain undocumented and is left to the choice or experience of the architects and developers thus leaving vulnerabilities in the application, which hackers exploit to launch an attack on the enterprise's digital assets. Security threats are on the rise and is now being considered as a Board Item as the impact of security breach is very high and could cause monetary and non monetary losses.

One of the key aspects of the IT Governance is to ensure that the investments made in software assets are optimal and there is a quantifiable return on such investments. This also means that such investment does not lead to risks that could lead to damages. Most of us are well aware that reviews play a key role in ensuring the quality of the software assets. As such, in this blog post, I have tried to come up with a checklist for reviewing the architecture and design of a software application.

While the choice of specific design best practice is interdependent on another, a careful tradeoff is necessary. For a detailed discussion on Trade off Analysis of Software Quality Attributes. Each of the checklist item listed here needs further elaboration and identification of specific practices, which will depend on the enterprise architecture and design principles of the organization.

Deployment Considerations

  • The design references the security policy of the organization and is in compliance of the same.
  • The application components are designed to comply with the various networking and other infrastructure related security restrictions like firewall rules, using appropriate secure protocols, etc.
  • The trust level with which the application accesses various resources are known and are in line with the acceptable practices.
  • The design supports the scalability requirements such as clustering, web farms, shared session management.
  • The design identifies the configuration / maintenance points, and the access to the same is manageable.
  • Communication with various local or remote components of the application is using secure protocols.
  • The design addresses performance requirements by adhering to relevant design best practices.

Application Architecture Considerations

Input Validation

  • Whether the design identifies all entry points and trust boundaries of the application.
  • Appropriate validations are in place for all inputs that comes from ourside the trust boundary.
  • The input validation strategy that the application adopted is modular and consistent.
  • The validation approach is to constrain, reject, and then sanitize input.
  • The design addresses potential canonicalization issues.
  • The design addresses SQL Injection, Cross Site Scripting and other vunerabilities
  • The design applies defense in depth to the input validation strategy by providing input validation across tiers.
Authentication
  • The design identifies the identities or roles that are used to access resources across the trust boundaries.
  • Service account or such other predefined identity requirements to, if so needed to access variuos system resources are identified and documented.
  • User credentials or authentication tokens are stored in secure manner and access to the same is appropriately controlled and managed.
  • Where the credentials are shared over the network, appropriate security protocol and encryption techniques are used.
  • Appropriate account management policies are considered.
  • In case of authentication failures, the error information displayed is minimal so that it does not reveal any clues that could make the credential guessing easier.
  • The design adopts a policy of using least-privileged accounts.
  • Password digests with salt are stored in the user store for verification.
  • Password rules are defined so that the stronger passwords are enforced.
Authorization
  • The user role design offers sufficient separation of privileges and considers authorization
  • granularity.
  • Multiple gatekeepers are envisaged for defense in depth.
  • The application’s identity is restricted in the database to access-specific stored procedures and does not have permissions to access tables directly.
  • Access to system level resources are restricted unless there is an absolute necessity.
  • Code Access Security requirements are established and considered.
Configuration Management
  • Stronger authentication and authorization is considered for access to administrration modules.
  • Secure protocols are used for remote administration of the application.
  • Configuration data is stored in a secured store and access to the same is appropriately controlled and managed
  • Least-privileged process accounts and service accounts are used.
Sensitive Data
  • Design recognizes sensitive data and considers appropriate checks and controls on the same.
  • Database connections, passwords, keys, or other secrets are not stored in plain text.
  • The design identifies the methodology to store sensitive data securely. Appropriate algorithms and
  • key sizes are used for encryption. 
  • Error logs, audit logs or such other application logs does not store sensitive data in plain text.
  • The design identifies protection mechanisms for sensitive data that is sent over the network.
Session Management
  • The contents of authentication cookies are encrypted.
  • Session lifetime is limited and times out upon expiration.
  • Session state is protected from unauthorized access.
  • Session identifiers are not passed in query strings.
Cryptography
  • Platform-level cryptography is used and it has no custom implementations.
  • The design identifies the correct cryptographic algorithm and key size for the application’s data encryption requirements.
  • The methodology to secure the encryption keys is identified and the same is in line with the acceptable best practices.
  • The design identifies and establishes the key recycle policy for the application.
Parameter Manipulation
  • All input parameters are validated including form fields, query strings, cookies, and HTTP headers.
  • Sensitive data is not passed in query strings or form fields.
  • HTTP header information is not relied on to make security decisions.
  • View state is protected using MACs.
Exception Management
  • The design outlines a standardized approach to structured exception handling across the application.
  • Application exception handling minimizes the information disclosure in case of an exception.
  • Application errors are logged to the error log, and the design provides for periodic review of such logs.
  • Sensitive data is not logged as part of the error logs, but where necessary, the same is logged with appropriate de-identification technique
Auditing and Logging
  • The design identifies the level of auditing and logging necessary for the application and identifies the key parameters to be logged and audited.
  • The design considers how to flow caller identity across multiple tiers at the operating system or application level for auditing.
  • The design identifies the storage, security, and analysis of the application log files