Information Security Concepts
Content
Information Security Concepts: Confidentiality, Integrity, Availability, and Authenticity
Introduction
In information security theory we encounter the acronym CIA--which does not stand for a governmental agency--but instead for Confidentiality, Integrity, and Availability. You say, "Clemmer, why are these concepts so important?" Well, without any one, or in fact all of them, business operations, transactions, and communications can become unreliable, untrustworthy, and uncertain. In this article series we will examine each of these concepts as IT goals, and discover how we may accomplish them. I also want to identify and add a fourth important concept: Authenticity. We may take away from this discussion a new acronym: CIAA.
Confidentiality
This means, at the core of the concept, that the data is hidden from those that are not supposed to see it. Read more about this in my articles: Debunking The Top 10 Security Myths: 6-10, and Security Through Obscurity--Boon or Bane? We can accomplish Confidentiality in a number of ways. These methods are complementary. First, require strong authentication for any access to data. Second, use strict access controls. In communications only the sender and intended recipient should be able to access the data. In file systems and data repositories, only the creator and intended users can access the data. Third, ensure encryption of the data so that it cannot be intercepted, and cannot be accessed during transmission or transport.
Integrity
Integrity as a concept means that there is resistance to alteration or substitution of data, and/or that such changes are detected and provable. The information should not be changed except by an authorized agent. This usually involves the use of checksums, one-way hashes, or other algorithmic validation of the data. Whether the data might be changed by accident or malice, preventing that change is the foremost concern, and detecting if it has changed is second. Integrity can be maintained at many levels, from the hardware all the way to the application logic.
Availability
For our data to be of use to us, it has to be accessible when and where we need it. Therefore part of the puzzle is how to keep our data available. Attacks or accidents can bring down systems. Data can be overwritten, deleted, or destroyed. Denial of Service attacks can make otherwise fast-access systems run like cold molasses. High Availability solutions, including load balancing, fail-over, and quick backup and restoration are all involved. In my opinion these topics are network and systems architecture concerns, operations concerns, and not truly a primary security component. I think we ought to, when considering security issues, place Authenticity as a higher priority than Availability! If my data is available 24/7 but it's not the data I believed it was, then having it available is pointless.
Authenticity
At first glance it might seem that Authenticity is included in the concept of Integrity. Integrity is more specifically about the content of the data itself. Authenticity means that when I get an order from Bob, it's verifiably Bob that's placing the order. The order (the data) is of no value if Bob didn't want to place it. So, Authenticity involves assurance that the data was created or sent by the source it appears to be from. Not verifying authenticity is tied to current problems with spam, e-mail phishing, web site redirection, browser hijacking, or other attacks such as man-in-the-middle attacks.
Information Security Concepts: Confidentiality
Confidentiality is one of four core concepts of Information Security examined in this series of articles. To understand Confidentiality, we must understand the concept of privacy. Further, we must have an understanding of what information should be protected, and how to define "authorized." To understand Confidentiality, we must understand the concept of privacy. Further, we must have an understanding of what information should be protected, and how to define "authorized" and intended access. At the core, Confidentiality comprises the idea that specific information should not be accessible by those that are not supposed to see it. All sorts of business and personal information is created, stored, and exchanged. Information could be details of everyday business operations, sales information, marketing, bills and invoices, or many other things. For most of these types of
information, there is not an overreaching expectation of extreme privacy or secrecy. It might not be ideal if how much a business spends on electricity became public knowledge, but in reality that bit of information isn't a mission critical secret. Conversely, for any business performing high-volume transactions with customer credit card information as payment, the customers card information is extremely important to protect.
Confidential Information
So, how do we decide what information should be confidential? We need to consider several factors. First, what's the relative value of the information? What is the risk if it is exposed? Have you or your business been entrusted with the information, with the understanding that it won't be shared with any other party? We might categorize information in the following way: Completely Private ("Eyes Only"), Private / High Value, Internal, Preferred, and Public. Public information is easy to understand. You almost certainly want customers to know that you're going to be selling the XYZ widget for $99 starting next Monday. Preferred information might involve a business partner knowing your Research and Development budget for next year--not something you want everyone to know, but some people should know it. You may not want your competition to know that you've signed a contract that will allow you to outsource production of those XYZ widgets for a 25% reduction in cost. That information might be Internal, or High Value depending upon your business or market. Completely Private information would include things like trade secrets, user passwords, and the like.
Keeping It Confidential
You say: "Clemmer, the theory makes sense, but how do we make it work in practice?" How do we protect information that we know should be kept confidential? In Information Technology we use the following elements: Authentication, Authorization, and Access Control. Authentication should come first: Is the person or agent who they claim to be? In the physical world we might check a picture ID, or have them present a card and enter a PIN. Comupter systems at minimum should ask for a user ID and password. Authorization comes next: What is this agent's role? Are they a member of a group or department that has access to the information in question? Roles can be things like Accounting, Engineering, Customer, Business Manager, and so forth. Access Control involves what the agent can or can't do, based on their role. Can they (and should they be able to) read, write, change, add, or delete information?
Conclusion
As we can see, there are implications and concerns with Confidentiality that reach every aspect of modern business. Knowing what information you have, what its value is, and what the risks are if it is not kept confidential are the key concepts. These apply whether the information is electronic, printed, or even verbally exchanged. Employee and customer education, along with clarity in communications are key. Something as simple as a "Company Confidential" stamp on a printed document can make a big difference. Next we will examine the concept of information Integrity, focusing on what that really means in modern business and why it is important.
Information Security Concepts: Integrity
Integrity is the next of four core concepts of information security examined in this series. Integrity, in Information Technology terms, means that data remains unchanged while stored or transmitted. Unauthorized changes to stored data violate integrity.
What is Integrity?
Integrity is the next of four core concepts of information security examined in this series. Integrity, in Information Technology terms, means that data remains unchanged while stored or transmitted. Once in place, changes should only be possible to data if the change is authorized. In modern business, enormous amounts of information are created, transmitted, and stored daily. We almost always make the assumption that entries on a web form, e-mails we send, or documents saved will have and retain the data we intended. But how valid is this assumption? Why do we make it? You say: "Clemmer, what are you talking about? Of course that data's not going to change!" But it can change, by accident, mistake, or malice.
Accident, mistake, or malice
Accidents happen, so not all integrity failures are due to malice. Integrity failure could be caused by noise or transmission errors, bad sectors or hard disk crashes, or errors in data entry or capture. Tape media are subject to data degradation, EMF erasure, and wear. Optical media can be scratched. Mistakes can be made by users, customers, or administrators.
We must also beware of malicious changes to data. Such changes may be harder to detect. They may be plausible and otherwise contextually valid. An example might be a "shifted decimal point" in a payment, where $100.00 becomes $10,000. These sorts of attacks on data integrity are often imagined to originate with wily hackers, but could surely come from a disgruntled employee as well. Of course malicious changes also include damage done to programs by viruses, trojans, or worms.
Verifying and retaining integrity
Computational techniques for verifying data integrity include: comparisons, checksums, message authentication & integrity codes (MAC/MIC), and message digests such as MD5 or SHA-1 hashes. For example, the Message Digest 5 (MD5) hash is a mathematical algorithm which produces a unique 128 bit number (a hash) created from the data input. If even one bit of data changes, the hash value will change. An example of this in use: most open source programs and packages are distributed along with an MD5 hash. Before installing, the recipient can generate the MD5 hash, and compare it with the (known good) hash provided by the source. If the generated and provided hashes are not the same, the program or package has been changed. Simpler checksum techniques such as cyclic redundancy checks (CRC) are built-in to hard drives. Modern hard drives also have additional Integrity protection, as they may contain error correction technology, automatically reconstructing data in failing sectors and moving it to new sectors to preserve it.
Conclusion
Modern information systems are far more reliable today than ten or twenty years ago, but failures still happen. Sound operational policies and practices can help minimize the risks of accidental and mistake-based integrity failures. As computational costs have decreased, and requirements for secure data more prevalent, built-in integrity solutions have become more common.
Information Security Concepts: Availability
Availability is the third of four concepts examined in this series of articles. In the ubiquitous Internet and wireless access era, information must be available 24/7, or whenever it's needed. All the effort spent securing data from unauthorized access or integrity failures may go to waste.
Availability Defined
In the ubiquitous Internet and wireless access era, information must be available 24/7, or whenever it's needed. All the effort spent securing data from unauthorized access or integrity failures may go to waste if it is not accessible when and where it is needed. Business operations rely critically on digital information and electronic information transfer. Perfect backups and massive servers are useless if system and network uptime is minimal. Unreliability brings inefficiency, a recipe for failure. Fortunately, there are numerous solutions available to increase availablity. Solutions may be simple or complex, ranging in cost from almost free to as much as you want to spend!
Is it available?
How do we ensure our information is available? In planning, determine optimized computing and memory capacity, plan for growth, and predict peak usage requirements. High-availability solutions are becoming more affordable and simpler. Load balancing and fail-over solutions should be part of the design, not an add-on or a future consideration. These solutions don't just improve performance; they simplify maintenance, and most importantly in this discussion, ensure availability. Virtual server farms make increasing load capacity simpler, and make restores much faster. If these things don't seem that important to you yet, ask yourself: what is the real cost if employees can't do their jobs; if customers can't be serviced? Aren't planned costs for a better infrastructure better than unplanned costs for a crisis?
Dangers to Availability
Availability can be compromised in many ways. Denial of Service (DoS) attacks can bring down networks, servers, or applications. A hacker or disgruntled employee could delete important data. If the network is penetrated, control of servers or network hardware can be usurped. In many cases these attacks happen through worms, like Conficker, without any person's conscious knowledge or intent during the attack. There are many points of failure. Anything, from a server, a database, an application, the LAN, WAN, Wireless net, or Internet connectivity could have an outage. Accidental downtime is possible too, of course. Like Integrity, loss of availability could occur due to error(s) on the part of the support or operations staff.
Conclusion
Inclusion of Availability in the traditional "CIA Triad" is the subject of considerable debate. Over the years I have leaned toward the side of the argument that availability is more of an IT Operations responsibility than an Information Security issue. I see the role of Information Security staff in assuring availability, of course. The reality is that the
implementation & support of solutions that guarantee availability are the responsibility in practice of the Operations staff and management.
Information Security Concepts: Authenticity
Authenticity is the fourth and final core concept we will explore. What do we mean by authenticity in Information Security? Authenticity is assurance that a message, transaction, or other exchange of information is from the source it claims to be from. Authenticity involves proof of identity.
What is authenticity?
What do we mean by authenticity in Information Security? Authenticity is assurance that a message, transaction, or other exchange of information is from the source it claims to be from. Authenticity involves proof of identity. We can verify authenticity through authentication. The process of authentication usually involves more than one "proof" of identity (although one may be sufficient). The proof might be something a user knows, like a password. Or, a user might prove their identity with something they have, like a keycard. Modern (biometric) systems can also provide proof based on something a user is. Biometric authentication methods include things like fingerprint scans, hand geometry scans, or retinal scans.
Ensuring authenticity
For user interaction with systems, programs, and each other, authentication is critical. User ID and password input is the most prevalent method of authentication. It also seems to present the most problems. Passwords can be stolen or forgotten. Cracking passwords can be simple for hackers if the passwords aren't long enough or not complex enough. Remembering dozens of passwords for dozens of applications can be frustrating for home users and business users alike. Single Sign On (SSO) solutions Two-factor or multi-factor authentication is more common in the enterprise for mission critical applications and systems. Mulit-factor authentication systems may use Key cards, smart cards, or USB tokens. Public Key Infrastructure (PKI) Authentication uses digital certificates issued by a central or 3rd party authority. Secure Socket Layer (SSL)
connections to web sites provide not only encryption for the session, but also (usually) provide verification that the web site is authentically the site it claims to be.
The importance of authenticity
Despite the prevalence of spam, and the ease of spoofing e-mail source addresses, email is still one of the universal applications that rarely provides authenticity for the recipient. Ironically, almost all modern e-mail solutions include the capability to use digital certificates. Public PKI systems that are free or very inexpensive are available. Still, understanding and implementing user certificates in e-mail applications and browsers is difficult for the average Internet user. Of course, with the sheer volume of messaging on the Internet, it may seem unrealistic to expect the authenticity of every message sent and received to be verified or verifiable! But why? Is it too much to ask for all planned systems in development to include not just the option, but guarantee of message authenticity? Scams, cons, and identity theft seem to be important enough issues that this should be a selling point, and to justify the cost.
What to do?
As an individual, consider options such as using stronger passwords that are easy for you to remember but hard for anyone else to guess. Take a second look before responding to unusual e-mails or entering personal or financial information on web sites. For businesses, look into multi-factor authentication for your critical business applications, PKI, and SSO. Educate users on security policy and practices to verify authenticity. Audit existing systems to ensure authentication is present, effective, and strong enough for the systems protected.
Information Security Concepts Fundamental Information Security Concepts are important in creating security policies, procedures, and IT business decisions. This article examines Information Security concepts such as CIA: Confidentiality, Integrity, and Availability, as well as Authenticity.
Data Security Guidelines and Methodologies
A White Paper, June 2006
Daniel Adinolfi, CISSP [email protected] Senior Security Engineer Cornell Information Security Office Data security practices must be factored into the design and implementation of any information service. It is in the best interests of the people whose personal data we maintain that we prevent disclosure of that data to unauthorized parties. Also, we feel that it is in our best interests to protect institutional data, ensuring its integrity and availability. Finally, because of data privacy laws such as FERPA, HIPAA, GLBA, or the New York State Security and Notification Act, we must work to prevent any loss of data that is regulated by those laws and reduce the effect of any potential compromises. The confidentiality, integrity, and availability of your data must be a priority for any application that is being purchased or built by local developers. Confidentiality is the concept that data will only be viewable by those who are explicitly permitted to view it. Integrity is the concept that data will not change in unexpected or unauthorized ways. Whatever processes or users affect the data will do so predictably and without errors. Availability is the idea that your application and the data within it will be accessible to the intended audience whenever that access is needed and not accessible to those who do not require access. This differs from confidentiality in that it addresses the uptime of a service and how users communicate with it. When considering confidentiality, integrity, and availability, the following questions should be asked:
What would be the consequences if data were to be accessed by someone who is not authorized to access it? What would be the consequences if data were modified in a way that was outside the expected mechanisms? What would be the consequences if the data or server were made unavailable when it is needed?
As a general rule, for confidentiality and availability, the concept of "least privilege" should be considered: access to data resources should be limited in such a way that only the very least amount of access should be permitted per task and per user. For integrity, testing should be performed before any system is implemented to ensure the data does not become corrupted and
regular logging and log analysis should be performed to provide debugging and assistance with incident response. This is part of the larger need to perform a risk analysis weighing the costs of user and process auditing versus the cost of data loss from incidents that involve abuse of access by authorized and unauthorized users. The exact requirements that you will have for your data and services with regards to confidentiality, integrity, and availability will depend on a number of factors. One factor is the presence of federal, state, or local legislation regulating the data. Also, Cornell and its departments and units have their own set of regulations that must be factored in, specifically those in University Policy Volume 4, "Governance". There is an on-going policy effort to better define data categories and the minimal security requirements for those categories. Data stewards, the Cornell Policy Office, and CIT are collaborating in this effort. There are certain questions that should be asked before either a product evaluation or internal service design. The answers to these questions will help set the requirements for that evaluation or design. Also, consider the sensitivity of the data in question and whether there should be special requirements for data access and security.
What entities or individuals will require access to the data or service in question? For example, will users be accessing the data from campus? From home? From specific subnets on campus? What is the least amount of data that each of those entities or individuals will require? From where will the data be accessed? What are the availability requirements for this access? 24x7? Business hours? What regulations, if any, affect the data being utilized by this service? For example, student records are covered by FERPA, medical data is covered by HIPAA, and financial data is covered by GLBA.
Though the focus of this document is on the development and implementation of networked services, consideration must be made to all hosts that will hold the sensitive data being processed by those services. This includes database servers, proxies, or user systems, to name a few. Security recommendations for user systems can be found at the following web pages: Twelve Steps toward Securing Windows or Macintosh Desktop Computers http://www.cit.cornell.edu/security/computer Recommended Security Practices for Cornell Departments and Units http://www.cit.cornell.edu/security/depth/strategy/unit_recs.cfm
Implementation Considerations
When specific technologies are evaluated, the following should also be considered. The answers to these questions will help indicate how well security has been designed into the service.
Where will data be stored? How will it be stored?
What mechanisms will be used to access the data? For example, is this a web-based application? Does it use its own client? What is the protocol used to communicate over the network? What logging is available through the operating systems on which the application runs? From the application itself? What authentication and authorization mechanisms are available? How are those mechanisms maintained? (Authentication is the process of verifying the identity of the user. Authorization is restricting access based on a user's identity.) Who is responsible for the maintenance and upkeep of each component of the service in question? For example, who will maintain the OS, the appliation, any databases, etc.? What can be done to reduce the impact of a disaster affecting the service?
As one can see, some of these questions are related to specific technological issues where others have more to do with management and administrative methodologies. Security controls can be designed to affect both the technical and the administrative sides of a particular service.
Technical Options
From a technical point of view, a number of technologies can be leveraged to secure a service and its data.
On the network side, packet filtering, via firewalls or router access control lists, can be used to limit what traffic can reach the servers. Servers running services should be placed on separate subnets from end user systems. Intrusion detection systems can offer logging and monitoring for network-based attacks and unusual network behavior. Communications between all the components of the service, both client-server communication and server-server communication, should also be considered. Is sensitive data being sent in such a way that it could be intercepted and compromised?
The hosts themselves should be securely configured, implementing technology to address:
patch management, remote access, OS-level integrity verification, application integrity verification, and secure data storage.
Also, server processes and logs should be monitored and reported on in an organized fashion. The processes built into and around the service and the policies that are applied to it address the administrative side of the service's security posture. An appropriate password and authorization policy should be created for the service based on the access requirements. For services that utilize sensitive data, year user awareness classes should be held to ensure the users understand the regulatory and institutional security requirements that apply to the data. Yearly audits of the service should be performed to ensure all the components conform to the security policies assigned to it.
The physical security requirements of the systems running the service must be considered as well. Sufficient heating, cooling, and air conditioning must be provisioned. Also, backup power systems should be implemented to help ensure the availability requirements will be satisfied in the event of power incidents. Also, the systems should be isolated in such a way to ensure only those authorized to physically access them can do so, whether this be through the use of a locked room or a locked rack in a server farm. The Cornell IT Security Office can assist with identifying the technical requirements and working through specific implementation details that will satisfy any security policy requirements.
Introduction
In information security theory we encounter the acronym CIA--which does not stand for a governmental agency--but instead for Confidentiality, Integrity, and Availability. You say, "Clemmer, why are these concepts so important?" Well, without any one, or in fact all of them, business operations, transactions, and communications can become unreliable, untrustworthy, and uncertain. In this article series we will examine each of these concepts as IT goals, and discover how we may accomplish them. I also want to identify and add a fourth important concept: Authenticity. We may take away from this discussion a new acronym: CIAA.
Confidentiality
This means, at the core of the concept, that the data is hidden from those that are not supposed to see it. Read more about this in my articles: Debunking The Top 10 Security Myths: 6-10, and Security Through Obscurity--Boon or Bane? We can accomplish Confidentiality in a number of ways. These methods are complementary. First, require strong authentication for any access to data. Second, use strict access controls. In communications only the sender and intended recipient should be able to access the data. In file systems and data repositories, only the creator and intended users can access the data. Third, ensure encryption of the data so that it cannot be intercepted, and cannot be accessed during transmission or transport.
Integrity
Integrity as a concept means that there is resistance to alteration or substitution of data, and/or that such changes are detected and provable. The information should not be changed except by an authorized agent. This usually involves the use of checksums, one-way hashes, or other algorithmic validation of the data. Whether the data might be changed by accident or malice, preventing that change is the foremost concern, and detecting if it has changed is second. Integrity can be maintained at many levels, from the hardware all the way to the application logic.
Availability
For our data to be of use to us, it has to be accessible when and where we need it. Therefore part of the puzzle is how to keep our data available. Attacks or accidents can bring down systems. Data can be overwritten, deleted, or destroyed. Denial of Service attacks can make otherwise fast-access systems run like cold molasses. High Availability solutions, including load balancing, fail-over, and quick backup and restoration are all involved. In my opinion these topics are network and systems architecture concerns, operations concerns, and not truly a primary security component. I think we ought to, when considering security issues, place Authenticity as a higher priority than Availability! If my data is available 24/7 but it's not the data I believed it was, then having it available is pointless.
Authenticity
At first glance it might seem that Authenticity is included in the concept of Integrity. Integrity is more specifically about the content of the data itself. Authenticity means that when I get an order from Bob, it's verifiably Bob that's placing the order. The order (the data) is of no value if Bob didn't want to place it. So, Authenticity involves assurance that the data was created or sent by the source it appears to be from. Not verifying authenticity is tied to current problems with spam, e-mail phishing, web site redirection, browser hijacking, or other attacks such as man-in-the-middle attacks.
Information Security Concepts: Confidentiality
Confidentiality is one of four core concepts of Information Security examined in this series of articles. To understand Confidentiality, we must understand the concept of privacy. Further, we must have an understanding of what information should be protected, and how to define "authorized." To understand Confidentiality, we must understand the concept of privacy. Further, we must have an understanding of what information should be protected, and how to define "authorized" and intended access. At the core, Confidentiality comprises the idea that specific information should not be accessible by those that are not supposed to see it. All sorts of business and personal information is created, stored, and exchanged. Information could be details of everyday business operations, sales information, marketing, bills and invoices, or many other things. For most of these types of
information, there is not an overreaching expectation of extreme privacy or secrecy. It might not be ideal if how much a business spends on electricity became public knowledge, but in reality that bit of information isn't a mission critical secret. Conversely, for any business performing high-volume transactions with customer credit card information as payment, the customers card information is extremely important to protect.
Confidential Information
So, how do we decide what information should be confidential? We need to consider several factors. First, what's the relative value of the information? What is the risk if it is exposed? Have you or your business been entrusted with the information, with the understanding that it won't be shared with any other party? We might categorize information in the following way: Completely Private ("Eyes Only"), Private / High Value, Internal, Preferred, and Public. Public information is easy to understand. You almost certainly want customers to know that you're going to be selling the XYZ widget for $99 starting next Monday. Preferred information might involve a business partner knowing your Research and Development budget for next year--not something you want everyone to know, but some people should know it. You may not want your competition to know that you've signed a contract that will allow you to outsource production of those XYZ widgets for a 25% reduction in cost. That information might be Internal, or High Value depending upon your business or market. Completely Private information would include things like trade secrets, user passwords, and the like.
Keeping It Confidential
You say: "Clemmer, the theory makes sense, but how do we make it work in practice?" How do we protect information that we know should be kept confidential? In Information Technology we use the following elements: Authentication, Authorization, and Access Control. Authentication should come first: Is the person or agent who they claim to be? In the physical world we might check a picture ID, or have them present a card and enter a PIN. Comupter systems at minimum should ask for a user ID and password. Authorization comes next: What is this agent's role? Are they a member of a group or department that has access to the information in question? Roles can be things like Accounting, Engineering, Customer, Business Manager, and so forth. Access Control involves what the agent can or can't do, based on their role. Can they (and should they be able to) read, write, change, add, or delete information?
Conclusion
As we can see, there are implications and concerns with Confidentiality that reach every aspect of modern business. Knowing what information you have, what its value is, and what the risks are if it is not kept confidential are the key concepts. These apply whether the information is electronic, printed, or even verbally exchanged. Employee and customer education, along with clarity in communications are key. Something as simple as a "Company Confidential" stamp on a printed document can make a big difference. Next we will examine the concept of information Integrity, focusing on what that really means in modern business and why it is important.
Information Security Concepts: Integrity
Integrity is the next of four core concepts of information security examined in this series. Integrity, in Information Technology terms, means that data remains unchanged while stored or transmitted. Unauthorized changes to stored data violate integrity.
What is Integrity?
Integrity is the next of four core concepts of information security examined in this series. Integrity, in Information Technology terms, means that data remains unchanged while stored or transmitted. Once in place, changes should only be possible to data if the change is authorized. In modern business, enormous amounts of information are created, transmitted, and stored daily. We almost always make the assumption that entries on a web form, e-mails we send, or documents saved will have and retain the data we intended. But how valid is this assumption? Why do we make it? You say: "Clemmer, what are you talking about? Of course that data's not going to change!" But it can change, by accident, mistake, or malice.
Accident, mistake, or malice
Accidents happen, so not all integrity failures are due to malice. Integrity failure could be caused by noise or transmission errors, bad sectors or hard disk crashes, or errors in data entry or capture. Tape media are subject to data degradation, EMF erasure, and wear. Optical media can be scratched. Mistakes can be made by users, customers, or administrators.
We must also beware of malicious changes to data. Such changes may be harder to detect. They may be plausible and otherwise contextually valid. An example might be a "shifted decimal point" in a payment, where $100.00 becomes $10,000. These sorts of attacks on data integrity are often imagined to originate with wily hackers, but could surely come from a disgruntled employee as well. Of course malicious changes also include damage done to programs by viruses, trojans, or worms.
Verifying and retaining integrity
Computational techniques for verifying data integrity include: comparisons, checksums, message authentication & integrity codes (MAC/MIC), and message digests such as MD5 or SHA-1 hashes. For example, the Message Digest 5 (MD5) hash is a mathematical algorithm which produces a unique 128 bit number (a hash) created from the data input. If even one bit of data changes, the hash value will change. An example of this in use: most open source programs and packages are distributed along with an MD5 hash. Before installing, the recipient can generate the MD5 hash, and compare it with the (known good) hash provided by the source. If the generated and provided hashes are not the same, the program or package has been changed. Simpler checksum techniques such as cyclic redundancy checks (CRC) are built-in to hard drives. Modern hard drives also have additional Integrity protection, as they may contain error correction technology, automatically reconstructing data in failing sectors and moving it to new sectors to preserve it.
Conclusion
Modern information systems are far more reliable today than ten or twenty years ago, but failures still happen. Sound operational policies and practices can help minimize the risks of accidental and mistake-based integrity failures. As computational costs have decreased, and requirements for secure data more prevalent, built-in integrity solutions have become more common.
Information Security Concepts: Availability
Availability is the third of four concepts examined in this series of articles. In the ubiquitous Internet and wireless access era, information must be available 24/7, or whenever it's needed. All the effort spent securing data from unauthorized access or integrity failures may go to waste.
Availability Defined
In the ubiquitous Internet and wireless access era, information must be available 24/7, or whenever it's needed. All the effort spent securing data from unauthorized access or integrity failures may go to waste if it is not accessible when and where it is needed. Business operations rely critically on digital information and electronic information transfer. Perfect backups and massive servers are useless if system and network uptime is minimal. Unreliability brings inefficiency, a recipe for failure. Fortunately, there are numerous solutions available to increase availablity. Solutions may be simple or complex, ranging in cost from almost free to as much as you want to spend!
Is it available?
How do we ensure our information is available? In planning, determine optimized computing and memory capacity, plan for growth, and predict peak usage requirements. High-availability solutions are becoming more affordable and simpler. Load balancing and fail-over solutions should be part of the design, not an add-on or a future consideration. These solutions don't just improve performance; they simplify maintenance, and most importantly in this discussion, ensure availability. Virtual server farms make increasing load capacity simpler, and make restores much faster. If these things don't seem that important to you yet, ask yourself: what is the real cost if employees can't do their jobs; if customers can't be serviced? Aren't planned costs for a better infrastructure better than unplanned costs for a crisis?
Dangers to Availability
Availability can be compromised in many ways. Denial of Service (DoS) attacks can bring down networks, servers, or applications. A hacker or disgruntled employee could delete important data. If the network is penetrated, control of servers or network hardware can be usurped. In many cases these attacks happen through worms, like Conficker, without any person's conscious knowledge or intent during the attack. There are many points of failure. Anything, from a server, a database, an application, the LAN, WAN, Wireless net, or Internet connectivity could have an outage. Accidental downtime is possible too, of course. Like Integrity, loss of availability could occur due to error(s) on the part of the support or operations staff.
Conclusion
Inclusion of Availability in the traditional "CIA Triad" is the subject of considerable debate. Over the years I have leaned toward the side of the argument that availability is more of an IT Operations responsibility than an Information Security issue. I see the role of Information Security staff in assuring availability, of course. The reality is that the
implementation & support of solutions that guarantee availability are the responsibility in practice of the Operations staff and management.
Information Security Concepts: Authenticity
Authenticity is the fourth and final core concept we will explore. What do we mean by authenticity in Information Security? Authenticity is assurance that a message, transaction, or other exchange of information is from the source it claims to be from. Authenticity involves proof of identity.
What is authenticity?
What do we mean by authenticity in Information Security? Authenticity is assurance that a message, transaction, or other exchange of information is from the source it claims to be from. Authenticity involves proof of identity. We can verify authenticity through authentication. The process of authentication usually involves more than one "proof" of identity (although one may be sufficient). The proof might be something a user knows, like a password. Or, a user might prove their identity with something they have, like a keycard. Modern (biometric) systems can also provide proof based on something a user is. Biometric authentication methods include things like fingerprint scans, hand geometry scans, or retinal scans.
Ensuring authenticity
For user interaction with systems, programs, and each other, authentication is critical. User ID and password input is the most prevalent method of authentication. It also seems to present the most problems. Passwords can be stolen or forgotten. Cracking passwords can be simple for hackers if the passwords aren't long enough or not complex enough. Remembering dozens of passwords for dozens of applications can be frustrating for home users and business users alike. Single Sign On (SSO) solutions Two-factor or multi-factor authentication is more common in the enterprise for mission critical applications and systems. Mulit-factor authentication systems may use Key cards, smart cards, or USB tokens. Public Key Infrastructure (PKI) Authentication uses digital certificates issued by a central or 3rd party authority. Secure Socket Layer (SSL)
connections to web sites provide not only encryption for the session, but also (usually) provide verification that the web site is authentically the site it claims to be.
The importance of authenticity
Despite the prevalence of spam, and the ease of spoofing e-mail source addresses, email is still one of the universal applications that rarely provides authenticity for the recipient. Ironically, almost all modern e-mail solutions include the capability to use digital certificates. Public PKI systems that are free or very inexpensive are available. Still, understanding and implementing user certificates in e-mail applications and browsers is difficult for the average Internet user. Of course, with the sheer volume of messaging on the Internet, it may seem unrealistic to expect the authenticity of every message sent and received to be verified or verifiable! But why? Is it too much to ask for all planned systems in development to include not just the option, but guarantee of message authenticity? Scams, cons, and identity theft seem to be important enough issues that this should be a selling point, and to justify the cost.
What to do?
As an individual, consider options such as using stronger passwords that are easy for you to remember but hard for anyone else to guess. Take a second look before responding to unusual e-mails or entering personal or financial information on web sites. For businesses, look into multi-factor authentication for your critical business applications, PKI, and SSO. Educate users on security policy and practices to verify authenticity. Audit existing systems to ensure authentication is present, effective, and strong enough for the systems protected.
Information Security Concepts Fundamental Information Security Concepts are important in creating security policies, procedures, and IT business decisions. This article examines Information Security concepts such as CIA: Confidentiality, Integrity, and Availability, as well as Authenticity.
Data Security Guidelines and Methodologies
A White Paper, June 2006
Daniel Adinolfi, CISSP [email protected] Senior Security Engineer Cornell Information Security Office Data security practices must be factored into the design and implementation of any information service. It is in the best interests of the people whose personal data we maintain that we prevent disclosure of that data to unauthorized parties. Also, we feel that it is in our best interests to protect institutional data, ensuring its integrity and availability. Finally, because of data privacy laws such as FERPA, HIPAA, GLBA, or the New York State Security and Notification Act, we must work to prevent any loss of data that is regulated by those laws and reduce the effect of any potential compromises. The confidentiality, integrity, and availability of your data must be a priority for any application that is being purchased or built by local developers. Confidentiality is the concept that data will only be viewable by those who are explicitly permitted to view it. Integrity is the concept that data will not change in unexpected or unauthorized ways. Whatever processes or users affect the data will do so predictably and without errors. Availability is the idea that your application and the data within it will be accessible to the intended audience whenever that access is needed and not accessible to those who do not require access. This differs from confidentiality in that it addresses the uptime of a service and how users communicate with it. When considering confidentiality, integrity, and availability, the following questions should be asked:
What would be the consequences if data were to be accessed by someone who is not authorized to access it? What would be the consequences if data were modified in a way that was outside the expected mechanisms? What would be the consequences if the data or server were made unavailable when it is needed?
As a general rule, for confidentiality and availability, the concept of "least privilege" should be considered: access to data resources should be limited in such a way that only the very least amount of access should be permitted per task and per user. For integrity, testing should be performed before any system is implemented to ensure the data does not become corrupted and
regular logging and log analysis should be performed to provide debugging and assistance with incident response. This is part of the larger need to perform a risk analysis weighing the costs of user and process auditing versus the cost of data loss from incidents that involve abuse of access by authorized and unauthorized users. The exact requirements that you will have for your data and services with regards to confidentiality, integrity, and availability will depend on a number of factors. One factor is the presence of federal, state, or local legislation regulating the data. Also, Cornell and its departments and units have their own set of regulations that must be factored in, specifically those in University Policy Volume 4, "Governance". There is an on-going policy effort to better define data categories and the minimal security requirements for those categories. Data stewards, the Cornell Policy Office, and CIT are collaborating in this effort. There are certain questions that should be asked before either a product evaluation or internal service design. The answers to these questions will help set the requirements for that evaluation or design. Also, consider the sensitivity of the data in question and whether there should be special requirements for data access and security.
What entities or individuals will require access to the data or service in question? For example, will users be accessing the data from campus? From home? From specific subnets on campus? What is the least amount of data that each of those entities or individuals will require? From where will the data be accessed? What are the availability requirements for this access? 24x7? Business hours? What regulations, if any, affect the data being utilized by this service? For example, student records are covered by FERPA, medical data is covered by HIPAA, and financial data is covered by GLBA.
Though the focus of this document is on the development and implementation of networked services, consideration must be made to all hosts that will hold the sensitive data being processed by those services. This includes database servers, proxies, or user systems, to name a few. Security recommendations for user systems can be found at the following web pages: Twelve Steps toward Securing Windows or Macintosh Desktop Computers http://www.cit.cornell.edu/security/computer Recommended Security Practices for Cornell Departments and Units http://www.cit.cornell.edu/security/depth/strategy/unit_recs.cfm
Implementation Considerations
When specific technologies are evaluated, the following should also be considered. The answers to these questions will help indicate how well security has been designed into the service.
Where will data be stored? How will it be stored?
What mechanisms will be used to access the data? For example, is this a web-based application? Does it use its own client? What is the protocol used to communicate over the network? What logging is available through the operating systems on which the application runs? From the application itself? What authentication and authorization mechanisms are available? How are those mechanisms maintained? (Authentication is the process of verifying the identity of the user. Authorization is restricting access based on a user's identity.) Who is responsible for the maintenance and upkeep of each component of the service in question? For example, who will maintain the OS, the appliation, any databases, etc.? What can be done to reduce the impact of a disaster affecting the service?
As one can see, some of these questions are related to specific technological issues where others have more to do with management and administrative methodologies. Security controls can be designed to affect both the technical and the administrative sides of a particular service.
Technical Options
From a technical point of view, a number of technologies can be leveraged to secure a service and its data.
On the network side, packet filtering, via firewalls or router access control lists, can be used to limit what traffic can reach the servers. Servers running services should be placed on separate subnets from end user systems. Intrusion detection systems can offer logging and monitoring for network-based attacks and unusual network behavior. Communications between all the components of the service, both client-server communication and server-server communication, should also be considered. Is sensitive data being sent in such a way that it could be intercepted and compromised?
The hosts themselves should be securely configured, implementing technology to address:
patch management, remote access, OS-level integrity verification, application integrity verification, and secure data storage.
Also, server processes and logs should be monitored and reported on in an organized fashion. The processes built into and around the service and the policies that are applied to it address the administrative side of the service's security posture. An appropriate password and authorization policy should be created for the service based on the access requirements. For services that utilize sensitive data, year user awareness classes should be held to ensure the users understand the regulatory and institutional security requirements that apply to the data. Yearly audits of the service should be performed to ensure all the components conform to the security policies assigned to it.
The physical security requirements of the systems running the service must be considered as well. Sufficient heating, cooling, and air conditioning must be provisioned. Also, backup power systems should be implemented to help ensure the availability requirements will be satisfied in the event of power incidents. Also, the systems should be isolated in such a way to ensure only those authorized to physically access them can do so, whether this be through the use of a locked room or a locked rack in a server farm. The Cornell IT Security Office can assist with identifying the technical requirements and working through specific implementation details that will satisfy any security policy requirements.
