Component Architecture
The Component Security Architecture is based on the view of “The Tradesman” and is the layer in which the implementation of the design(s) delivered collectively from the layers above is carried. This implementation is accomplished through the use of integrated components that are hardware items, software items, and interface specifications and standards (Sherwood, J., Clark, A., Lynas, D., 2005). In this layer:
- the assets (what) are defined by Detailed Data Structures
- the motivation (why) maps to the Security Standards
- the process (how) maps to the Security Products and Tools
- the people (who) are defined in the Identities, Functions, Actions, and ACLs
- the location (where) is defined within the Processes, Nodes, Addresses, and Protocols
- the time (when) is defined by the Security Step Timing and Sequencing
IPSEC
At a high level, IP Security (IPsec) is a suite of protocols used in securing the data exchanged between two points at the IP layer by way of a vpn tunnel. This data exchange can be between network devices, individuals, or organizations. The primary advantage of IPsec is that it’s virtually impossible to intercept traffic and decipher any captured data…which can also be a weakness, from a layered security (web content filtering/IDS/IPS) standpoint.
One of the glaring weaknesses of IPsec is the overhead associated with sending traffic through a vpn tunnel. The encryption/decryption of data has a noticeable performance impact on legacy technologies in the workplace (i.e. running applications (.exe programs) from shared drives w/in a network), and if QOS isn’t setup correctly, can also impact voice/video experiences when collaborating with others.
I’m a firm believer in leveraging IPsec for activities requiring the added layer of security in data/communications exchange, but for most operations over the public Internet, I feel comfortable relying upon the guidelines/standards communicated by NIST/ISO.
Within an enterprise environment, I believe there should be no IPsec-related traffic outside of that which is used for vpn-purposes. While not a silver bullet in identifying indicators of compromise, I would certainly consider it to be one of them. In addition, web traffic outbound should be decrypted and inspected by an inline device, which would also limit the ability of a compromised system to communicate without discovery.
One of the glaring weaknesses of IPsec is the overhead associated with sending traffic through a vpn tunnel. The encryption/decryption of data has a noticeable performance impact on legacy technologies in the workplace (i.e. running applications (.exe programs) from shared drives w/in a network), and if QOS isn’t setup correctly, can also impact voice/video experiences when collaborating with others.
I’m a firm believer in leveraging IPsec for activities requiring the added layer of security in data/communications exchange, but for most operations over the public Internet, I feel comfortable relying upon the guidelines/standards communicated by NIST/ISO.
Within an enterprise environment, I believe there should be no IPsec-related traffic outside of that which is used for vpn-purposes. While not a silver bullet in identifying indicators of compromise, I would certainly consider it to be one of them. In addition, web traffic outbound should be decrypted and inspected by an inline device, which would also limit the ability of a compromised system to communicate without discovery.
