Computer security

(Click to go to security links and search forms).

Security of computer applications is often taken to be "a technical issue" (i.e., something to be done by a separate group of specialists after the application functionality is delivered), or "a matter of policy," (i.e., dependent on management policy and user behavior) or simply "not my job."

At Outback Software we believe that security is a fundamental aspect of software architecture and design. Like reliability, usability, and other key aspects of quality, it must be managed from the start of the development process.

A development process that takes security into account involves these steps:

Security policy and requirements:   What are the security requirements mandated by organizational policy? Which requirements are expected to be handled by some mechanism (such as a firewall) external to the application under development, and which must be factored into application design? How much money and time is it economic to spend on security? Which risks are acceptable, and which are not? This step should be taken at the stage of systems analysis and feasibility study, and reviewed throughout the life of the project. Note that an overarching architecture for where security measures are implemented is an organization-wide responsibility, and is a prerequisite for the security policy for any particular application.

Architecture and design:    To be efficient and effective, facilities for authentication, protection of sensitive data, etc., must be designed in from the start. Every major building block in the system should have a defined security goal, or a statement that no security is required. Doing security "later" is always more expensive - in the worst case, resulting in serious loss that triggers a security retrofit.

Programming:    As Bruce Schneier says, "Writing a secure computer program is another matter entirely. Security involves making sure things work, not just in the presence of random faults, but in the face of an intelligent and malicious adversary trying to ensure that things fail in the worst possible way . . . it truly is programming Satan's computer" [16]. Programming for security requires specialized knowledge [22], and any module with a defined security goal should be peer-reviewed for compliance. From buffer overflows to weak cryptosystems, pitfalls abound, and may eventually be exploited if allowed to exist.

What are the threats and exposures? It is widely said that every enterprise that survives into the 21st century will be involved in e-commerce. Taking commerce in the broad sense of "dealings between groups or individuals in society," this is undoubtedly true - not just for commercial enterprises, but for nonprofits and governmental organizations as well. Access via the Internet is a requirement for any modern organization to deal with suppliers, partners, and customers. Thus every organization faces a similar landscape of electronic threats.

Since September 11th, 2001, we must consider computer security not just a matter of business security, but of national and global security. Even a computer system with no assets of value in themselves, if it is compromised, may be used as a platform for attacks on other systems. Attacks may come from anywhere in the world, the work of individuals, organizations, or states.

Security Issues in E-Commerce

As corporations move into the 21st century, they face many significant challenges: How to build on traditional differentiators in an increasingly wired world? How to keep their brands in sight of consumers bombarded with more and more electronic media advertising? How to leverage their existing IT infrastructure? Similar challenges face nonprofits and governmental organizations, as they try to become both more cost-effective and more responsive to their clients.

A lurking danger in this future is the threat to information security: How can data be protected from accidental or intentional misuse by people inside or outside the organization? Underlying the danger is a fundamental tension between data use, and data misuse:

• To support goals such as branding, sales volume, responsiveness to customers, and supply chain efficiency, organizations must provide an unpecedented level of access to data - to employees, customers, suppliers, even competitors.

• Misuse of information and computer resources is increasing, and causes substantial losses [1], [6]. Losses may stem from fraud, theft of service, theft of intellectual property, compromise of private data, or simply electronic vandalism. Yet the very things that support the goals above, such as network integration and Internet presence, increase the risk of accidental or malicious misuse or destruction of data.

• Regulatory requirements are increasing, and create additional conflicts. For example, in the U.S., the PATRIOT Act of 2001 [15] requires financial institutions to share more information on suspicious transactions and patterns of activity that might represent money laundering, while Title V of the Gramm-Leach-Bliley Act of 1999 [20] strengthens the rights of customers to keep their data private.

Faced with this tension, there are some typical reactions:

• "It won’t happen to us." This head-in-the-sand attitude ignores the fact that even computers with no valuable information may be used by intruders to launch attacks on other systems [7]. In addition, organizations that fail to exercise due care in securing their networks and computers may be held legally liable for loss of private information or damage to third-party computers [3], [5], [12], [27].

• "We’re OK, we have a firewall." Even for external attacks, firewalls are only one piece of a coordinated defense. And most studies conclude that the majority of damage is done by users inside the firewall [2], [17].

• "Security is a feature, we'll add it when we have time (or when the customer is willing to pay for it)" [29]. This attitude is particularly common among packaged software vendors, but in-house projects also suffer from it. Security is a basic, pervasive property of systems and applications, and "adding it later", even if effective, will not be cost-effective [18], [22].

Let’s step back and look at "bottom line" security issues. On the positive side of the ledger, corporate profits (or analogous metrics for nonprofits) are critically dependent on establishing trust relationships with customers, suppliers, and regulatory bodies. Looking at it from the converse perspective, organizations must avoid losses: loss of trust, theft of customer data or intellectual property, loss of the ability to serve customers, legal liability due to carelessness.

The possibility of loss is a risk, and risk avoidance involves costs. It is not cost-effective, or even possible, to completely eliminate risk. Each organization must decide what risks it is prepared to accept, and the appropriate level of safeguards. Generally there are tradeoffs not only between risk and cost, but also between risk and ease-of-use for customers.

Effective security risk management can be a competitive advantage, and it starts with an enterprise-wide analysis of threats, vulnerabilities, and possible countermeasures.

Security specialists model the bottom-line issues by saying that corporations need to protect these aspects of their data and transactions (see security models below):

• Confidentiality or privacy: Data must be seen only by authorized users.

• Integrity: Data must be secure from unauthorized modification, accidental or deliberate.

• Availability: Data and online services must be available when and where needed and authorized.

• Nonrepudiation or accountability: Anyone accessing or modifying data must be subject to audit, and be unable to subsequently deny what they have done. This applies both to the originator of a transaction, and to anyone who acts as an intermediary.

In order to insure that these protection goals are met, certain services must be provided by a secure system:

• Authentication: Establishing the identity of a user, and verifying that identity when any transaction is executed.

• Authorization or access control: Maintaining information on what operations are permitted for specific users, and insuring that unauthorized operations cannot be executed.

• Audits and alarms: Preserving a record of user actions, and detecting violations or attempted violations of authorization criteria.

These services may be provided at many different levels, and are typically provided in multiple places in an enterprise-wide network:

• A firewall may protect the network perimeter. Additional firewalls may protect the boundaries of intranets (portions of the network that are "internal use only"), extranets (servers provided to privileged external users such as business partners), and DMZs (web servers and other services provided to the public Internet). Firewalls provide audit and alarm capabilities, and a variety of low-level authentication and authorization mechanisms based on origin IP addresses, packet and session types, etc.

• Applications or application gateway hosts typically provide authentication, authorization, and audit services, which may be specialized for each application. Certain aspects of these services can be centralized; centralized authentication ("single sign-on") for example, may foster ease-of-use and authentication consistency, while providing stronger security through the use of smart cards, biometrics, etc. [19]

• Special applications such as intrusion detection systems [14], virus scanners, etc., may provide additional security for the entire network, specific servers, or individual hosts or applications.

Note that authentication and authorization may occur with respect to physical and logical devices (as in the case of firewalls) or programs (as in the case of virus scanners) as well as users. It is important not to make unwarranted assumptions about which user(s) are associated with these other entities.

Provision of multiple, redundant security services in the enterprise network may be good, to provide defense in depth against threats. On the other hand, if individual system and application managers have installed an uncoordinated collection of security tools, the result may be inconsistency, gaps in the security perimiter, inability to do assurance audits, and excessive cost.

To provide coherent, cost-effective security that is consistent with the organization’s security and risk management policies requires organization-wide analysis and planning. The result should be not just a collection of tools and technology, but an enterprise security architecture. This architecture ahould account for people, including users, developers, and managers, as well as technological artifacts. An architected solution has many advantages:

• The user experience of security across the organization is consistent.

• Development approaches to implementation of security features is consistent.

• Individual security implementations are transparent, that is, they can be mapped to the policies of the organization on security, permissible activities, and risk management.

• Systems are auditable, both in terms of user activity, and conformance to security policy.

• The overall solution is cost-effective, providing the required level of risk reduction at a reasonable cost.

This global view of enterprise information security has two dimensions: Spatial, across all the systems in the enterprise’s network, and transactional, an end-to-end view as transactions flow through the network.

Technology

The goals described above, of consistency, transparency, auditability, and cost-effective protection are facilitated by certain technical characteristics:

• Security service implementations should be portable, at least at the architectural level, and possibly at the code level. Implementation architecture should be driven by the business security requirements, not by individual vendor technology.

• Security service implementations should be open and interoperable. As far as possible, they should use common, standard interfaces and share data when necessary. Enterprise-wide intrusion detection is a particularly strong example of the value of this approach.

• Authentication and authorization services should be pluggable; that is, the design and implementation of these services in a manner consistent with organizational policy can be separated from the design and implementation of the served applications. Pluggability may imply reusable code modules added to an application, or servers accessed through a common interface, or both.

• Off-the-shelf applications that do not conform to common interface standards can be wrapped, that is, embedded in a code layer that translates between the common interface format and the vendor-specific format.

Two strong contenders in the arena of software technologies are the Java security API [10] and the emerging XML security standards [4], [23-25], [28]. The Java API provides services for individual applications such as authentication and encryption. Having standard, tested, reusable implementations for security components will enhance code quality and reduce vulnerabilities. Java also has many standard features, such as automatic array bounds checking, that make it inherently less vulnerable than C or C++ to certain kinds of attacks, such as buffer overflow. XML is the glue that allows security information such as authorization profiles and digital signatures to be shared among different applications. XML security protocols will come into their own with the emergence of web services, a distributed, componentized model for dynamically assembling business-to-business and business-to-consumer services.

When most people think of "security technology," what comes to mind is firewalls, router software, intrusion detection systems, etc. These off-the-shelf components are critical pieces of security architecture, but the importance of good coding practices within the development organization should not be overlooked.

With some exceptions, such as certain viruses and various "social engineering" attacks, all security vulnerabilities are ultimately based on defective code. Much of this is in vendor-supplied code that is not under the control of user organizations; but remember that the last line of defense in front of your data is your application code. Principles and practices for writing secure code are explained in Building Secure Software by Viega and McGraw [22].

In some areas, outsourcing is an alternative to having in-house technology expertise. It may make sense for tasks that require a significant skill depth, but are not done often enough to warrant having all the skills in-house. Configuration and management of firewalls and routers is one area where considerable outsourcing is done; intrusion detection is another [26]. Intrusion detection, in particular, seems like a good candidate: It can be done offsite from the customer, and doing it well demands a skilled corps of speciaists on duty 24/7, something small companies cannot provide for themselves [30]. Counterpane Internet Security, a good example, is well-established as an outsource supplier of security expertise. Mainstream "protection" companies such as Brink's are also entering the market as providers of computer security services.

Security Models

A number of models for security have been proposed. Some of the more important ones, with a comparison of their key concepts, are shown in the table below.

ISO 15408-1 ("Common Criteria") [9]	ISO 7498-2 (OSI Security Services) [8]	Information System Security Engineering Principles (NIST) [18]
Confidentiality (prevent unauthorised disclosure)	Data confidentiality	Confidentiality
	Authentication
	Access control
	Nonrepudiation
Integrity (prevent unauthorised modification)	Data integrity	Integrity
Availability (prevent loss of use)		Availability
	Security audit and alarms	Accountability
		Assurance

The "Common Criteria" were generated by an international effort to merge various security standards, such as the "Trusted Computer System Evaluation Criteria" developed by the U.S. Department of Defense in the 1980s. It was subsequently standardized by ISO (the International Standards Organization). The OSI Security Services model was part of the OSI (Open Systems Interconnection) effort, also done in the 1980s.

The NIST (National Institute of Standards and Technology) has set U.S. standards for encryption for several decades, and is now (particularly since 9/11/2001) heavily involved in computer security through their Computer Security Resource Center.

Another model of security, from the Hurwitz Group [11], is represented in this image, showing "the four disciplines" of security management:

Cutting across these disciplines are three activities: authentication, access control, and audit.

These models obviously have a lot in common. One way of reconciling their differences is to distinguish security goals from security mechanisms. Goals are the "what", mechanisms are the "how" of security. The three most commonly held goals are:

1. Confidentiality or privacy of data: Protection against disclosure to unauthorized parties.

2. Integrity of data: Protection against accidental or malicious alteration.

3. Availability of data: Protection from loss of access, e.g., due to denial-of-service attacks.

An additional goal, or perhaps meta-goal, is accountability: The ability to determine who has accessed or modified data. A closely associated goal is nonrepudiation: Insuring that a user who has accessed or modified information cannot deny doing so. (Nonrepudiation might also be considered a subgoal of accountability.) Assurance is another meta-goal, the result of a process that proves that other security goals have been met by a given system.

Mecahnisms for achieving these goals include:

• Authentication: Verification of the identity of an end user, remote system, etc.

• Authorization: Verification of the right of an identified user to perform a specified operation against specified data.

• Audits and alarms: The ability to preserve a record of user actions, and detect security violations or attempted violations.

Each of these mechanisms can be mapped to specific technology and vendors.

Yet another way of looking at security from a high level is to evaluate not the mechanisms or technology of security, but the process by which security is assessed and maintained. The Vulnerability Management Maturity Model is an example. Its "levels of growth" are knowledge, deployment, and accountability. This model is conceptually similar to the well-known Software Capability Maturity Model for software development organizations, from the Software Engineering Institute at Carnegie-Mellon University. The stages of the Software CMM itself could, with appropriate changes, be applied to the development of secure applications.

For more security information, links, and forms for searching security web sites, go to our security links and search forms page.

References

1. CSI (Computer Security Institute). CSI/FBI 2000 Computer Crime and Security Survey (PDF download).

2. Gaudin, Sharon. "The enemy within". Network World, May 8, 2000.

3. Greene, Tim. "Forum warns of hidden DDoS legal liability". Network World, October 2, 2000.

4. Hada , Satoshi and Michiharu Kudo. "XML Access Control Language: Provisional Authorization for XML Documents". IBM Tokyo Research Center, October 16, 2000.

5. Harris, Shon. "DoS Defense: Denying Denial-of-Service". Information Security, September 2001.

6. Hatcher, Thurston. "Survey: Costs of computer security breaches soar". CNN, March 12, 2001.

7. Houle, Kevin J., and George M. Weaver. Trends in Denial of Service Attack Technology (v1.0) (PDF download). October 2001. CERT Coordination Center.

8. ISO 7498. International Standards Organisation (ISO). Information processing systems - Open systems interconnection - Basic reference model - Part 2: Security architecture (ISO/IEC 7498-2). 1989.

9. ISO 15408. International Standards Organisation (ISO). Information technology - Security techniques - Evaluation criteria for IT security - Part 1: Introduction and general model (ISO/IEC 15408-1); Part 2: Security functional requirements (ISO/IEC 15408-2); Part 3: Security assurance requirements (ISO/IEC 15408-3). 1999.

10. Jaworski, Jamie, and Paul J. Perrone. Java Security Handbook. Indianapolis: SAMS, 2000.

11. Lindstrom, Pete. "Four Disciplines of Security Management" (PDF download). Hurwitz Group, 2001.

12. Matsuura, Jeffrey H. "Legal Liability and Distributed Denial of Service Attacks". TISC Insight 4, 3, 2002.

13. MIS Corporate Defence Solutions Ltd. "MIS Corporate Defence Solutions Warns End Users Against Security Over Spending". February 27, 2002.

14. SANS Institute. Intrusion Detection. SANS Information Security Reading Room, March 19, 2002.

15. Schneider, Ivan. "U.S. Treasury Prepares For USA PATRIOT Action". Bank Systems and Technology Online, 2002.

16. Schneier, Bruce. Forward to Ross Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems. New York: John Wiley & Sons, Inc., 2001.

17. Stephanou, Tony. "Assessing and Exploiting the Internal Security of an Organization" SANS Institute, March 13, 2001.

18. Stoneburner, Gary, et al. Engineering Principles for Information Technology Security (A Baseline for Achieving Security). National Institute of Standards and Technology (NIST) pub. SP 800-27, June 2001.

19. Trickey, Fred. "Secure Single Sign-On: Fantasy or Reality?" Computer Security Institute, 1997.

20. U.S. Senate. "Information Regarding the Gramm-Leach-Bliley Act of 1999".

21. Vasters, Clemens. "Why SOAP doesn't lack security while it does". newtelligence AG, 2000.

22. Viega, John, and Gary McGraw. Building Secure Software. Boston: Addison-Wesley, 2002.

23. Worldwide Web Consortium. "XML-Signature Syntax and Processing". October 31, 2000.

24. Worldwide Web Consortium. "XML Encryption Syntax and Processing". March 4, 2002.

25. Worldwide Web Consortium. "SOAP Security Extensions: Digital Signature". February 6, 2001.

26. Yasin, Rutrell. "Enterprises Size Up Managed Security". Internet Week, June 19, 2001.

27. Zimmerman , Scott C., Ron Plesco, and Tim Rosenberg. "Downstream Liability for Attack Relay and Amplification" (PDF download). RSA Conference, 2002.

28. Doll, Shelley. "XML security: A who's who". ZDNet Tech Update, July 8, 2002.

29. Acar, Tolga and John R. Michener. "Risks in Features vs. Assurance". Inside Risks 146, CACM 45, 8, August 2002.

30. Varine, Brian. "Should we outsource monitoring?". SANS Institute Intrusion Detection FAQ.