Deperimeterization

This article may be deleted soon.
	To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions. For the monthly nomination lists, see Category:Articles for deletion. Deperimeterization, also called perimeter erosion, is a relatively new term, popularized by the Jericho Forum of the Open Group, which deals with security issues in increasingly geographically distributed information technology. The group cites examples including: business transactions that tunnel through perimeters or bypass them altogether IT products that cross the boundary, encapsulating protocols within Web protocols security exploits that use email and Web to get through the perimeter It is finding utility in putting more and more meaningful frameworks around cloud computing, but it is not without controversy. Jericho emphasizes endpoint security, usually at the desktop level. This assumption has been challenged as conflicting with trends to let employees and contractors use their own computers and mobile devices. As Burton Group analysts put it, "If we don't own the end point device, how do we enforce software/application/configuration controls on them?" Jericho's model is one of secured subsystems and components rather than a single framework, using technologies such as encryption, " inherently secure communications and data-level authentication". They detail these as the : Jericho Fundamentals "The scope and level of protection should be specific and appropriate to the asset at risk. Business demands that security enables business agility and is cost-effective. Whereas boundary firewalls may continue to provide basic network protection, individual systems and data will need to be capable of protecting themselves." In general, it’s easier to protect an asset the closer protection is provided. Pervasive, scalable, simple Unnecessary complexity is a threat to good security. Coherent security principles are required which span all tiers of the architecture. Security mechanisms must scale; from small objects to large objects. To be both simple and scalable, interoperable security “building blocks” need to be capable of being combined to provide the required security mechanisms. Assume context at your peril Security solutions designed for one environment may not be transferable to work in another. Thus, it is important to understand the limitations of any security solution. Problems, limitations, and issues can come from a variety of sources, including geographic, legal, technical, acceptability of risk, etc. Surviving in a Hostile World Devices and applications must communicate using open, secure protocols "Security by obscurity is a flawed assumption – secure protocols demand open peer review to provide robust assessment and thus wide acceptance and use. The security requirements of confidentiality, integrity, and availability (reliability) should be assessed and built in to protocols as appropriate; not added on." Kerckhoffs' Principle and the Principle of Least Privilege are more than military axioms Encrypted encapsulation should only be used when appropriate and does not solve everything. Trusted contexts may not be available "All devices must be capable of maintaining their security policy on an un-trusted network" This generally implies end-to-end encryption, or at least end host to trusted security gateway. All Rules must be complete with respect to an arbitrary context. Any implementation must be capable of surviving on the raw break on any input." The Need for Trust All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place. Understandings, contracts and obligations Trust in this context is establishing understanding between contracting parties to conduct a transaction, and the obligations this assigns on each party involved. Trust models must encompass people/organizations and devices/infrastructure. Trust level may vary by location, transaction type, user role, and transactional risk. Mutual trust assurance levels must be determinable Devices and users must be capable of appropriate levels of (mutual) authentication for accessing systems and data. Authentication and authorization frameworks must support the trust model. Identity, Management, and Federation Authentication, authorization, and accountability must interoperate People/systems must be able to manage permissions of resources and rights of users they don't control. There must be capability of trusting an organization, which can authenticate individuals or groups, thus eliminating the need to create separate identities. In principle, only one instance of person/system/identity may exist, but privacy necessitates the support for multiple instances, or one instance with multiple facets. Systems must be able to pass on security credentials/assertions. Multiple loci (areas) of control must be supported. Access to Data Control by security attributes of the data itself "Attributes can be held within the data (DRM/metadata) or could be a separate system. "Some data may have “public, non-confidential” attributes. • "Access and access rights have a temporal component." Just as digital certificates expire and no longer grant access, there valid analogies to automatic declassification of most government classified information after a certain period of time. Segregation of duties/privileges Permissions, keys, privileges, etc. must ultimately fall under independent control, or there will always be a weakest link at the top of the chain of trust. Administrator access must also be subject to these controls. Secure data when stored, in transit, and in use "Removing the default must be a conscious act," another way to state the Principle of Least Privilege. "High security should not be enforced for everything; “appropriate” implies varying levels with potentially some data not secured at all." The more onerous the security, the more the end user is tempted to circumvent it. Questions about endpoint centrality If the endpoint is not controllable, then control has to be associated with the data, such as encryption tied to individual user identity. It may require data leakage protection (DLP), which scans for sensitive data such as credit card numbers. Other problems, which may be beyond the skill level of the end user, involve such things as malware. "Device control" may mean blocking the use of USB "thumb drives", especially without encryption, which could let the data move to an unknown endpoint. How will the needs of the owner of the data, to perform data discovery, be reconciled with the privacy of the user? There are many questions with no simple answers.