Showing posts with label Computer Systems Security. Show all posts
Showing posts with label Computer Systems Security. Show all posts
Guide for Applying the Risk Management Framework to Federal Information Systems
[External Reference]
[Computer Systems Security]
[Standards]
[Security Management]
[Risk Management]
[NIST]
Guide for Applying the Risk Management Framework to Federal Information Systems
NIST 800-37
Introduction
Organizations depend on information technology and the information systems that are developed from that technology to successfully carry out their missions and business functions. Information systems can include as constituent components, a range of diverse computing platforms from high-end supercomputers to personal digital assistants and cellular telephones. Information systems can also include very specialized systems and devices (e.g., telecommunications systems, industrial/process control systems, testing and calibration devices, weapons systems, command and control systems, and environmental control systems). Federal information and information systems are subject to serious threats that can have adverse impacts on organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation by compromising the confidentiality, integrity, or availability of information being processed, stored, or transmitted by those systems. Threats to information and information systems include environmental disruptions, human or machine errors, and purposeful attacks. Cyber attacks on information systems today are often aggressive, disciplined, well-organized, well-funded, and in a growing number of documented cases, very sophisticated. Successful attacks on public and private sector information systems can result in serious or grave damage to the national and economic security interests of the United States. Given the significant and growing danger of these threats, it is imperative that leaders at all levels of an organization understand their responsibilities for achieving adequate information security and for managing information system-related security risks.
The full document is available through the following link:
http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf
CLOUD COMPUTING: A REVIEW OF FEATURES, BENEFITS, AND RISKS, AND RECOMMENDATIONS FOR SECURE, EFFICIENT IMPLEMENTATIONS
[External Reference]
[Computer Systems Security]
[Standards]
[Cloud Computing]
[NIST]
CLOUD COMPUTING: A REVIEW OF FEATURES, BENEFITS, AND RISKS, AND RECOMMENDATIONS FOR SECURE, EFFICIENT IMPLEMENTATIONS
NIST 800-146
Executive Summary
Cloud computing allows computer users to conveniently rent access to fully featured applications, to software development and deployment environments, and to computing infrastructure assets such as network-accessible data storage and processing.
This document reprises the NIST-established definition of cloud computing, describes cloud computing benefits and open issues, presents an overview of major classes of cloud technology, and provides guidelines and recommendations on how organizations should consider the relative opportunities and risks of cloud computing. Cloud computing has been the subject of a great deal of commentary. Attempts to describe cloud computing in general terms, however, have been problematic because cloud computing is not a single kind of system, but instead spans a spectrum of underlying technologies, configuration possibilities, service models, and deployment models. This document describes cloud systems and discusses their strengths and weaknesses.
Depending on an organization's requirements, different technologies and configurations are appropriate. To understand which part of the spectrum of cloud systems is most appropriate for a given need, an organization should consider how clouds can be deployed (deployment models), what kinds of services can be provided to customers (service models), the economic opportunities and risks of using cloud services (economic considerations), the technical characteristics of cloud services such as performance and reliability (operational characteristics), typical terms of service (service level agreements), and the security opportunities and risks (security).
The full document is available through the following link:
http://www.thecre.com/fisma/wp-content/uploads/2012/05/sp800-146.pdf
A Framework for Assessing and Improving Enterprise Architecture Management (Version 2.0)
[External Reference]
[Computer Systems Security]
[Standards]
[Security Management]
[Software Architecture]
[Enterprise Architecture]
A Framework for Assessing and Improving Enterprise Architecture Management (Version 2.0)
GAO-10-846G
Why GAO did this study
Effective use of an enterprise architecture (EA) is a hallmark of successful organizations and an essential means to achieving a desired end: having operations and technology environments that maximize institutional mission performance and outcomes. Among other things, this includes realizing cost savings through consolidation and reuse of shared services and elimination of antiquated and redundant mission operations, enhancing information sharing through data standardization and system integration, and optimizing service delivery through streamlining and normalization of business processes and mission operations. Not using an EA can result in organizational operations and supporting technology infrastructures and systems that are duplicative, poorly integrated, unnecessarily costly to maintain and interface, and unable to respond quickly to shifting environmental factors.
To assist organizations in successfully developing, maintaining, and using an EA, GAO is issuing this major update to its Enterprise Architecture Management Maturity Framework. Its purpose is to provide a flexible benchmark against which to plan for and measure EA program maturity. To develop the update, GAO solicited comments from 27 federal departments and agencies, as well as representatives from the private sector, state governments, and academia, and it leveraged its prior experience in applying the framework.
The full document is available through the following link:
http://www.gao.gov/assets/80/77233.pdf
NIST Standards on How to Secure Operating Systems
[External Reference]
[Computer Systems Security]
[Standards]
[Security Management]
[OS Security]
[NIST]
NIST Standards on How to Secure Operating Systems
NIST 800-70 v2
National Checklist Program Repository (NCP)
A full featured guide tool with checklists and security benchmarks for all operating systems and devices (from mainframes to mobile devices). It is based on the NIST 800-70 v2 standard. A must have reference source for the security professional.
The link for the National Checklist Program Repository is:
http://web.nvd.nist.gov/view/ncp/repository
Recommended Security Controls for Federal Information Systems and Organizations
[External Reference]
[Computer Systems Security]
[Standards]
[Security Management]
[NIST]
Recommended Security Controls for Federal Information Systems and Organizations
NIST 800-53 v3
Introduction
The Need For Security Controls to Protect Information and Information Systems
The selection and implementation of appropriate security controls for an information system4 or a system-of-systems5 are important tasks that can have major implications on
the operations6 and assets of an organization7 as well as the welfare of individuals and the
Nation. Security controls are the management, operational, and technical safeguards or countermeasures employed within an organizational information system to protect the confidentiality, integrity, and availability of the system and its information. There are several important questions that should be answered by organizational officials when addressing the security considerations for their information systems:
- What security controls are needed to adequately mitigate the risk incurred by the use of information and information systems in the execution of organizational missions and business functions?
- Have the selected security controls been implemented or is there a realistic plan for their implementation?
- What is the desired or required level of assurance (i.e., grounds for confidence) that the selected security controls, as implemented, are effective8 in their application?
The answers to these questions are not given in isolation but rather in the context of an effective information security program for the organization that identifies, mitigates as deemed necessary, and monitors on an ongoing basis, risks9 arising from its information and information systems. The security controls defined in this publication and recommended for use by organizations in protecting their information systems should be employed in conjunction with and as part of a well-defined and documented information security program. The program management controls (Appendix G), complement the security controls for an information system (Appendix F) by focusing on the organization-wide information security requirements that are independent of any particular information system and are essential for managing information security programs.
The full document is available through the following link:
http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf
Computer Securitye Incident Handling Guide
[External Reference]
[Computer Systems Security]
[Standards]
[Security Management]
[Incident Handling]
[NIST]
Computer Security Incident Handling Guide
NIST 800-61 v2
Abstract
Computer security incident response has become an important component of information technology (IT) programs. Because performing incident response effectively is a complex undertaking, establishing a successful incident response capability requires substantial planning and resources. This publication assists organizations in establishing computer security incident response capabilities and handling incidents efficiently and effectively. This publication provides guidelines for incident handling, particularly for analyzing incident-related data and determining the appropriate response to each incident. The guidelines can be followed independently of particular hardware platforms, operating systems, protocols, or applications.
The full document is available through the following link:
http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf
Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)
[External Reference]
[Computer Systems Security]
[Standards]
[Security Management]
[NIST]
[PII]
Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)
NIST 800-122
Executive Summary
The escalation of security breaches involving personally identifiable information (PII) has contributed to the loss of millions of records over the past few years.1 Breaches involving PII are hazardous to both individuals and organizations. Individual harms2 may include identity theft, embarrassment, or blackmail. Organizational harms may include a loss of public trust, legal liability, or remediation costs. To appropriately protect the confidentiality of PII, organizations should use a risk-based approach; as McGeorge Bundy3 once stated, ―If we guard our toothbrushes and diamonds with equal zeal, we will lose fewer toothbrushes and more diamonds.‖ This document provides guidelines for a risk-based approach to protecting the confidentiality4 of PII. The recommendations in this document are intended primarily for U.S. Federal government agencies and those who conduct business on behalf of the agencies,5 but other organizations may find portions of the publication useful. Each organization may be subject to a different combination of laws, regulations, and other mandates related to protecting PII, so an organization‘s legal counsel and privacy officer should be consulted to determine the current obligations for PII protection. For example, the Office of Management and Budget (OMB) has issued several memoranda with requirements for how Federal agencies must handle and protect PII. To effectively protect PII, organizations should implement the following recommendations.
The full document is available through the following link:
http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf
An Introduction to Computer Security: The NIST Handbook
[External Reference]
[Computer Systems Security]
[Standards]
[NIST]
An Introduction to Computer Security: The NIST Handbook
NIST 800-12
Purpose
This handbook provides assistance in securing computer-based resources (including hardware, software, and information) by explaining important concepts, cost considerations, and interrelationships of security controls. It illustrates the benefits of security controls, the major techniques or approaches for each control, and important related considerations.
The handbook provides a broad overview of computer security to help readers understand their computer security needs and develop a sound approach to the selection of appropriate security controls. It does not describe detailed steps necessary to implement a computer security program,
provide detailed implementation procedures for security controls, or give guidance for auditing the security of specific systems. General references are provided at the end of this chapter, and references of "how-to" books and articles are provided at the end of each chapter in Parts II, III and IV.
The purpose of this handbook is not to specify requirements but, rather, to discuss the benefits of various computer security controls and situations in which their application may be appropriate. Some requirements for federal systems2 are noted in the text. This document provides advice and guidance; no penalties are stipulated.
The full document is available through the following link:
http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf
[Computer Systems Security]
[Standards]
[NIST]
An Introduction to Computer Security: The NIST Handbook
NIST 800-12
Purpose
This handbook provides assistance in securing computer-based resources (including hardware, software, and information) by explaining important concepts, cost considerations, and interrelationships of security controls. It illustrates the benefits of security controls, the major techniques or approaches for each control, and important related considerations.
The handbook provides a broad overview of computer security to help readers understand their computer security needs and develop a sound approach to the selection of appropriate security controls. It does not describe detailed steps necessary to implement a computer security program,
provide detailed implementation procedures for security controls, or give guidance for auditing the security of specific systems. General references are provided at the end of this chapter, and references of "how-to" books and articles are provided at the end of each chapter in Parts II, III and IV.
The purpose of this handbook is not to specify requirements but, rather, to discuss the benefits of various computer security controls and situations in which their application may be appropriate. Some requirements for federal systems2 are noted in the text. This document provides advice and guidance; no penalties are stipulated.
The full document is available through the following link:
http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf
Information Security Handbook: A Guide for Managers
[External Reference]
[Computer Systems Security]
[Standards]
[Security Management]
[NIST]
Information Security Handbook: A Guide for Managers
NIST 800-100
Introduction
This Information Security Handbook provides a broad overview of information security program elements to assist managers in understanding how to establish and implement an information security program. Typically, the organization looks to the program for overall responsibility to ensure the selection and implementation of appropriate security controls and to demonstrate the effectiveness of satisfying their stated security requirements. The topics within this document were selected based on the laws and regulations relevant to information security, including the Clinger-Cohen Act of 1996, the Federal Information Security Management Act (FISMA) of 2002, and Office of Management and Budget (OMB) Circular A-130. The material in this handbook can be referenced for general information on a particular topic or can be used in the decision-making process for developing an information security program. National Institute of Standards and Technology (NISTIR) Interagency Report 7298 provides a summary glossary for the basic security terms used throughout this document. While reading this handbook, please consider that the guidance is not specific to a particular agency. Agencies should tailor this guidance according to their security posture and business requirements.
The full document is available through the following link:
http://csrc.nist.gov/publications/nistpubs/800-100/SP800-100-Mar07-2007.pdf
Trusted Computer Systems Evaluation Criteria
[External Reference]
[Computer Systems Security]
[Standards]
[NIST]
Department of Defense
Trusted Computer Systems Evaluation Criteria
DoD 5200.28-STD
Preface
The trusted computer system evaluation criteria defined in this document classify systems into four broad hierarchical divisions of enhanced security protection. They provide a basis for the evaluation of effectiveness of security controls built into automatic data processing system products. The criteria were developed with three objectives in mind: (a) to provide users with a yardstick with which to assess the degree of trust that can be placed in computer systems for the secure processing of classified or other sensitive information; (b) to provide guidance to manufacturers as to what to build into their new, widely-available trusted commercial products in order to satisfy trust requirements for sensitive applications; and (c) to provide a basis for specifying security requirements in acquisition specifications. Two types of requirements are delineated for secure processing: (a) specific security feature requirements and (b) assurance requirements. Some of the latter requirements enable evaluation personnel to determine if the required features are present and functioning as intended. The scope of these criteria is to be applied to the set of components comprising a trusted system, and is not necessarily to be applied to each system component individually. Hence, some components of a system may be completely untrusted, while others may be individually evaluated to a lower or higher evaluation class than the trusted product considered as a whole system. In trusted products at the high end of the range, the strength of the reference monitor is such that most of the components can be completely untrusted. Though the criteria are intended to be application-independent, the specific security feature requirements may have to be interpreted when applying the criteria to specific systems with their own functional requirements, applications or special environments (e.g., communications processors, process control computers, and embedded systems in general). The underlying assurance requirements can be applied across the entire spectrum of ADP system or application processing environments without special interpretation.
The full document is available through the following link:
http://csrc.nist.gov/publications/history/dod85.pdf
[Computer Systems Security]
[Standards]
[NIST]
Department of Defense
Trusted Computer Systems Evaluation Criteria
DoD 5200.28-STD
Preface
The trusted computer system evaluation criteria defined in this document classify systems into four broad hierarchical divisions of enhanced security protection. They provide a basis for the evaluation of effectiveness of security controls built into automatic data processing system products. The criteria were developed with three objectives in mind: (a) to provide users with a yardstick with which to assess the degree of trust that can be placed in computer systems for the secure processing of classified or other sensitive information; (b) to provide guidance to manufacturers as to what to build into their new, widely-available trusted commercial products in order to satisfy trust requirements for sensitive applications; and (c) to provide a basis for specifying security requirements in acquisition specifications. Two types of requirements are delineated for secure processing: (a) specific security feature requirements and (b) assurance requirements. Some of the latter requirements enable evaluation personnel to determine if the required features are present and functioning as intended. The scope of these criteria is to be applied to the set of components comprising a trusted system, and is not necessarily to be applied to each system component individually. Hence, some components of a system may be completely untrusted, while others may be individually evaluated to a lower or higher evaluation class than the trusted product considered as a whole system. In trusted products at the high end of the range, the strength of the reference monitor is such that most of the components can be completely untrusted. Though the criteria are intended to be application-independent, the specific security feature requirements may have to be interpreted when applying the criteria to specific systems with their own functional requirements, applications or special environments (e.g., communications processors, process control computers, and embedded systems in general). The underlying assurance requirements can be applied across the entire spectrum of ADP system or application processing environments without special interpretation.
The full document is available through the following link:
http://csrc.nist.gov/publications/history/dod85.pdf
The Security Tools Every Security Professional Should Know About
[External Reference]
[Computer Systems Security]
[Security Tools]
[Networking]
The Security Tools Every Security Professional Should Know About
The full list of security tools is available at:
http://sectools.org/
[Computer Systems Security]
[Security Tools]
[Networking]
The Security Tools Every Security Professional Should Know About
The full list of security tools is available at:
http://sectools.org/
Internet Standards - RFCs
[External Reference]
[Networking]
[Internet]
[RFC]
[Standards]
A complete list of all Internet standards and RFCs.
The list is available at:
http://www.rfc-editor.org/categories/rfc-standard.html
[Networking]
[Internet]
[RFC]
[Standards]
A complete list of all Internet standards and RFCs.
The list is available at:
http://www.rfc-editor.org/categories/rfc-standard.html
Understanding Security Using the OSI Model
[External Reference]
[Networking]
[Computer Systems Security]
[OSI]
Understanding Security Using the OSI Model
Abstract
This paper is written as a guide for those who do not labor through the wee hours
of the morning (yet) studying every new Information Technology (IT) vulnerability. This
paper will provide a breakdown of the OSI (Open Source Interconnection) model, and
using that model, explain some well-known vulnerabilities. The paper will take each
layer of the OSI model (there are seven) and describe a relevant vulnerability with a
solution to that problem area. The reader will become more aware of the vulnerabilities
that exist in the IT environment. More importantly, the reader will be able to use the OSI
model as a guide to simplify the security process.
The full paper is available at:
http://www.sans.org/reading_room/whitepapers/protocols/understanding-security-osi-model_377
[Networking]
[Computer Systems Security]
[OSI]
Understanding Security Using the OSI Model
Abstract
This paper is written as a guide for those who do not labor through the wee hours
of the morning (yet) studying every new Information Technology (IT) vulnerability. This
paper will provide a breakdown of the OSI (Open Source Interconnection) model, and
using that model, explain some well-known vulnerabilities. The paper will take each
layer of the OSI model (there are seven) and describe a relevant vulnerability with a
solution to that problem area. The reader will become more aware of the vulnerabilities
that exist in the IT environment. More importantly, the reader will be able to use the OSI
model as a guide to simplify the security process.
The full paper is available at:
http://www.sans.org/reading_room/whitepapers/protocols/understanding-security-osi-model_377
SIP& VoIP: Assessing the Security Aspects of SIP-based Communications
[SIP]
[VoIP]
[Computer Systems Security]
[Networking]
[Internet]
Abstract
The ubiquity of the Internet has driven the development of many disrupting technologies in the last decades. Transitioning communication systems from circuit-switching to packet-switching made sense and was a natural step in the evolution of communication technology. The transmission of voice and multimedia over the global network depends on reliable and sophisticated protocols, capable of, among other things, discovering, authenticating, and linking communication endpoints. However, the excitement and demand that surrounds emerging technologies are almost always accompanied by security concerns. In this context, this research will explore the Session Initiation Protocol (SIP) and its applicability towards Voice-over-IP (VoIP) solutions, while assessing the security aspects of Denial of Service Attacks (DoS) on SIP-based systems.
SIP& VoIP: Assessing the Security Aspects of SIP-based Communications
The Internet has enabled individuals and Enterprises with instant access to all kinds of media. The now retiring traditional telephony networks are being replaced by Internet-based Voice over IP (VoIP) systems that offer equivalent, if not better, audio quality, compact and sometimes cheaper equipment, incredibly low calling prices, and innumerous extra features such as automatic call answering, call blocking, call forwarding, call waiting, fax capabilities, multi-way calling, contact lists, distinctive ringing, local number portability, voicemail, and many more. However, since data networks were not originally designed for real-time media-rich telephony services, new communication protocols and Internet standards had to be defined and enforced to enable the migration from circuit-switched to packet-switched voice transmission and conferencing services.
The need for a new standard protocol, that could enable extended interactivity through real-time media and data sharing by managing how computers find and connect to each other, pushed the creation of the Session Initiation Protocol (SIP). SIP is a signaling protocol, currently defined by the Internet Engineering Task Force (IETF) RFC 3261, capable of setting up, maintaining, and cleaning up the established sessions between computers. Other protocols exist for supporting VoIP implementations (i.e. H.323, H.248, and etc…), but they are not as simple, robust and popular as SIP, which is why SIP became the focus of this research.
SIP, however, does not support all the existing features of the VoIP systems by itself. Instead, it collaborates with many other standards (e.g. protocols, processes, and services) to accomplish this task, such as Transmission Control Protocol (TCP), Network Time Protocol (NTP), User Datagram Protocol (UDP), Stream Control Protocol (SCTP), Domain Name System (DNS), Hypertext Transfer Protocol (HTTP), Trivial File Transfer Protocol (TFTP), Simple Network Management Protocol (SNMP), Dynamic Host Configuration Protocol (DHCP), Resource Reservation Protocol (RSVP), Session Description Protocol (SDP), Real-time Transport protocol (RTP), Transport Layer Security (TLS), and etc.
This paper will describe in details how SIP supports VoIP implementations, while assessingthe security aspects of Denial of Service Attacks (DoS) in SIP-based systems.
The SIP Protocol
The dependency of the SIP protocol on other Internet processes and protocols to support VoIP applications is present since its origins. According to Porter, Jr., & Baskin (2006), the original draft for the Session Invitation Protocol (SIP v1) was submitted on February 22, 1996 to the IETF by Mark Handley and Eve Schooler.
On that same day, Henning Schulzerinne submitted to the IETF a draft specifying the Simple Conference Invitation Protocol (SCIP) – a protocol used to enable session management for point-to-point and multicast sessions.
SIPv1 – The Session Invitation Protocol
SIPv1 was text-based and used UDP as its transport protocol. It used the Session Description Protocol (SDP) as the basic mechanism to manage multimedia sessions. On SIPv1, workstations needed to be registered against an address server before sessions could be established. If the user was working remotely or in a different workstation from his own, that workstation could be temporarily registered to the address server, enabling users to establish sessions with other registered computers. However, there was no way to know if the user was available for connection establishment. If he was available, once a session was established, the work performed by SIPv1 was done. At that point, SIP v1was still very immature as a signaling protocol, accounting only for session establishment among computers. There were no conference controls available and no mechanism to tear down the sessions.
SCIP was HTTP-based and used TCP as its transport protocol allowing for both synchronous and asynchronous communications. SCIP had a more universal approach for identifying registered computers. It used e-mail address like identification instead of plain IP address as workstation identifiers within the registration servers. This allowed for greater mobility over both synchronous and asynchronous connections. It also defined a new format for handling multimedia sessions. SCIP extended beyond the session establishment by defining mechanisms to modify session parameters in active sessions. SCIP was also responsible for closing the session and “cleaning up the house” (i.e. resetting parameters and deallocating used resources) once the session was over.
SIPv2 – The Session Invitation Protocol
By the end of 1996 both the SIPv1 and SCIP protocols were merged to give birth to the Session Initiation Protocol (SIP) – also known as SIPv2. The SIPv2 protocol was HTTP-based and allowed for both UDP and TCP sessions, using SDP to describe multimedia sessions. By December 1997, to easy the work of reviewing and enhancing the protocol, the IETF decided to split SIPv2 into a basic specification and a set of extensions. By February 1999, the protocol as published for the first time as an IETF standard (RFC 2543).
RFC 3261 – The current SIP standard
On June 2002, after the review of the RFC 2543 was completed, the SIP protocol was republished as an IETF standard (RFC 3261). The new SIP protocol was based on HTTP and SMTP and used TCP, UDP, and SCTP as transport
According to IETF.com (2002), the new SIP standard was responsible for establishing, managing, and terminating multimedia sessions, among multiple computers, besides locating and inviting computers (participants) for these sessions. RFC 3261 summarizes the inner-works of the SIP protocol as follows:
"SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers…”(IETF.com, 2002)
The computers participating in a SIP session are identified by their Universal Resource Identifier (URI), based the following formats: sip:username:password@host:portfor unencrypted sessions or sips:username:password@host:portfor TLS encrypted sessions. Applications running in these computers (i.e. messaging, games, VoIP, media-rich conferences, and etc…), which depend on real-time communications can use SIP to interact and share data with each other. SIP, however, is not responsible for the actual transport of the media streams.
“The Real-time Transport Protocol RTP is an application-level protocol which is intended for delivery of delay-sensitive content, such as audio and video, through different networks.” (Falk & Fries, 2008) “The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.” (IETF.com, 2003) Thus, SIP uses the RTP protocol for transport of real-time media.
Once the SIP sessions are established, a direct virtual path, supported by the RTP protocol, is established between the endpoints of the session. This way, media is exchanged in real time through the RTP path while signaling messages are exchanged in parallel using the the SIP protocol throughout the life of the session.
Now that we learned a little bit more about the evolution of the SIP protocol and its current implementation we are ready to start investigating more deeply the protocol. To avoid any confusion among the different SIP standards, the term SIP will be used from now on to define the current version of the SIP standard, as published on IETF’s RFC 3621.
SIP and the Open Systems Interconnection Model (OSI)
The OSI model is used to describe communication protocols through a set of layers, specifying how the various protocols are capable of exchanging data among computers within a network and how the protocols relate to each other. The SIP protocol is considered as an application layer protocol. This means that user applications interact directly with the protocol to make use of its functionality.
SIP Architecture
As mentioned before, the rich set of features available through SIP to support VoIP applications is dependent on many other protocols, services, and network devices. To better understand the security vulnerabilities of the SIP protocol and VoIP applications, we need first to understand the SIP architecture.
SIP Components
Following is a brief description of the components that integrate the SIP architecture:
- User Agents (UAs): the participants of a session (i.e. software application – softphone, PDA, IP phone, connection, and etc.). UAs can communicate with other components through either client/server or peer-to-peer architectures. Each participant is equipped with the following components:
o User Agent Client (UAC): subcomponent responsible for issuing SIP requests.
o User Agent Server (UAS): subcomponent responsible for responding to UA requests.
- SIP Servers: computers capable of locating and identifying participants, besides facilitating (routing) the exchange of SIP messages among them. These servers can run in either stateless or stateful modes, caching or not all the SIP messages they process. SIP Servers can communicate with other components through either client/server or peer-to-peer architectures.
o Registrar Server: stores the UAs’ locations of the active computers on the network, based on their IP address and logged username. The registrar server also provides participant information to other servers through a service (daemon) known as Location Service.
o Proxy Server: forwards requests (SIP messages) among UAs and SIP servers. The proxy server makes use of the information stored in the Registrar servers to locate the participants and verify their statuses (i.e. online, offline, away, busy, and etc…).
o Redirect Server: redirects UACs requests to the UAs they are trying to connect to. Instead of forwarding messages as the proxy server does, the redirect server returns to the UAC the URI identification of the target UA and tell the UAC to contact the UA directly (in a peer-to-peer way). If the targeted UA is a participant registered in more than one location, the redirect server will split the session to the various UA’s locations. For example, if an UAA placed a call to a multi-location UABn (where “n” is the index of the targeted location), the phone on all the targeted UAB’s locations will ring. Only the first participant who accepted the call (for example, UAB0, UAB1, or UAB2, in the case of a participant registered in 3 different locations) will be used for the session, the other UAs will be discarded for that specific session.
IP Requests and SIP Responses
The HTTP-like characteristic of the SIP protocol allows for text-based messages that are exchanged among UAs (UACs and UASs) and SIP servers. Following is a list of the main SIP messages:
- REGISTER: used by the UAs to register both the SIP and IP addresses with the SIP Registrar Servers.
- INVITE: used to establish SIP session between UAC.
- OPTIONS: used to query the UAs capabilities (i.e. session parameters, media types to be exchanged, and etc…).
- NOTIFY: transmits information about the message’s originator UA.
- SUBSCRIBE: used to verify presence status of a specific UA (i.e. online, away, offline, available, busy, and etc…).
- ACK: used to acknowledge the exchange and correct processing of SIP messages.
- BUY: terminates a session.
- CANCEL: cancels a pending request without terminating the session.
After SIP messages are sent by either the UAs or SIP servers a response is always sent back to the message’s originator. These responses, also known as SIP responses, are grouped as follows:
- (1xx) Informational responses: informs the sender that its request was received and is being processed.
- (2xx) Success: informs the sender that its message was acknowledged and accepted.
- (3xx) Redirection: informs the sender that its message redirection may be necessary before its SIP message can be processed.
- (4xx) Client Error: informs the sender that its request was malformed and cannot be processed.
- (5xx) Server Error: Informs the sender that his request cannot be processed by one of the available SIP servers. The message may be forwarded to the next active and available server for processing retry.
- (6xx) Global Error: Informs the sender that his request cannot be processed by one of the available SIP servers. The message will not be redirected for reprocessing.
Please note that the list of specific SIP responses is huge. Thus, only the main response categories were described and the full list was omitted for brevity reasons.
Security Concerns on VoIP and SIP-based implementations
The incredible features provided by VoIP implementations far outpace the features offered by traditional circuited-switched telephony systems. However, “although VoIP was designed to be secure, VoIP technology faces many security threats nowadays.” (Garuba, Jiang,& Zhenqiang, 2008) Also, with the introduction of VOIP, “the need for security is compounded because now we must protect two invaluable assets, our data and our voice” (Nist.gov, 2005)
The dependence of VoIP on the SIP protocol and SIP extensions makes it vulnerable to most network attacks. As an application layer protocol, the SIP protocol is dependent on the lower layers of the OSI model, which makes it susceptible to any weaknesses that may affect these layers, including, among other things, Internet Protocol (IP) infrastructure vulnerabilities, operating system vulnerabilities, configuration vulnerabilities, and general network attacks. For the purposes of this research, we will focus on the effects of DoS attacks on SIP-based systems.
Denial of Service (DoS) Attacks
Denial of Service attacks are carried out by overloading the network components, in this case, UAs, SIP servers, and other network devices, with malicious traffic causing disruption of network services, degrading Quality of Service (QoS) and, occasionally, bringing down the entire network. Attacks may target any active port, through either DoS or Distributed Denial of Service (DDoS) attacks. In VoIP and SIP-based implementations, attackers may target specific ports, such as:
- 5060 port: used for non-encrypted SIP traffic for both TCP and UDP protocols.
- 5061 port: used for SIP traffic encrypted with TLS for both TCP and UDP protocols.
it is worth to note that, depending on the network configuration and branding of the network components, the port numbers may vary.
General DoS Attacks
Following is a list of some of the main DoS attacks:
- Ping Flood Attack: ports are overloaded with Internet Control Message Protocol (ICMP) Echo request packets, normally used when the attacker has more bandwidth than the victim. Targeted ports may then respond with ICMP Echo Reply packets, which consume both bandwidth and CPU cycles.
- Ping of Death (PoD) Attack: ports are overloaded with malicious traffic, crafted to ensure that packets with sizes bigger than 65,535 bytes. According to IETF.com (1981), the IP protocol (RFC 791) would be violated if a packet with such characteristics is sent through the network, unless the pack is sent in a fragmented format. Once the packet arrives on the port and is reassembled by the targeted computer, buffer overflow can occur causing the system to crash.
- Smurf Attack: this attack targets the public Internet by exploiting and flooding poorly configured network devices with maliciously crafted Internet Protocol (IP) packets. These packets are broadcasted to all linked hosts on a particular network via its broadcast address in an amplified manner, instead of targeting a specific host. This quickly consumes network bandwidth, blocking the processing of valid packets.
- SYN Flood Attack: ports listening over the TCP protocol are overloaded with crafted SYN messages, which are normally responsible for establishing the connection between a client and a server machine. Once a server receives a SYN message, it extracts the IP address of the message’s sender and prepares to establish a connection. In this case, since the sender’s address is forged, the acknowledgement message to establish the connection never returns to the server, causing it to be in a“wait” state. If too many connections are opened, the server will cease to accept connection requests for as long as the attack continues.
- Permanent DoS (PDoS) Attack: exploits security flaws of the target machines, generally embedded devices with lower internal security, to gain administrative access to its interfaces. Once access is acquired, the attacker updates the firmware of networked devices with malformed images, breaking the devices.
- Banana Attack: it overloads communication ports in targeted devices with a feedback mechanism, were outgoing traffic from the target is redirected to itself or to other devices in an out-of-sequence way, affecting and possibly disabling external access to these devices.
- Distributed Reflected DoS (DRDoS) Attack: Echo broadcast requests are crafted with a spoofed sender address, which will be the IP address of the targeted device, and sent to a huge number of computers on a poorly configured network. The computers are expected to reply to the targeted machine, flooding it and disrupting its operation. This attack is also considered as an amplification attack.
- Malware propagation: viruses and worms may cause DoS or DDoS attacks on QoS dependent networks, as a consequent burst of network traffic due to the malware’s replication and propagation efforts.
- Unintentional DoS: the targeted computer is flooded by a sudden burst of requests, as a result of unpreparedness to handle unforeseen popularity of its services due to extensive or even unexpected advertisement campaigns.
From General DoS Attacks to VoIP and SIP-based Implementations
The list of possible DoS attacks is big and its effects can be even bigger on the enterprises and individuals which businesses depend on VoIP and SIP implementations. The DoS attacks described above can be easily adapted to target the specifics of VoIP environments. To illustrate the equivalence of the general DoS attacks to VoIP, let’s consider a few examples:
- PoD Attack Targeting UA devices: as presented on the general description of the PoD attack, or Ping of Death attack, maliciously crafted data packets with sizes bigger than 65,535 bytes could be sent over UDP to the port 5060 of the UA devices (i.e. IP phones), causing them to crash.
- Malware infection on VoIP environments: since both SIP and RTP – the supporting protocol used to perform the actual exchange of real-time media streams among UAs, are extremely time-dependent (QoS dependency), a malware infection could affect the network’s quality of service by increasing the network traffic as a consequence of the malware’s replication process.
- Registrar Server Flooding Attack: by capturing and resending SIP REGISTER messages to the Registrar Servers, these servers can reach the limit of allowed registrations per second, becoming unable of registering new UAs and consequently blocking the SIP protocol from establishing new sessions for these UAs.
- Packet Replay Attack: By capturing and resending SIP packets in an out-of-sequence format an attacker can add delays to the VoIP network, affecting the quality of service. This attack is similar in many ways to the previously described Banana attack.
- DoS Attack against SIP Supporting Services: by attacking SIP supporting services (i.e. DHCP, DNC, and etc…) an attacker can affect the SIP protocol and consequently the VoIP application. For example, In a DHCP-based network, if the DHCP server is attacked and disabled, UAs and SIP Servers will become unable to exchange date, maintain, or establish sessions new sessions.
- Deceiving DoS Messages Attack: by sending valid but fake SIP messages to UAs and SIP servers, it is possible to cause busy conditions and session disconnections in the very same way DoS SYN attacks work.
- SIP Packet of Death Attack: by flooding the UAs and SIP Servers with random and out-of-sequence TCP, UDP, and ICPM packets, the VoIP network can collapse due to increased CPU usage, bandwidth consumption, and blocked services.
These are just a few examples of attacks derived from the extensive list of general DoS attacks that are used against VoIP and SIP implementation. In fact, this list does not intent, by any means, to be a complete reference.
DoS Attacks – Countermeasures
To realize the benefits of VoIP and SIP-based implementations, it is necessary to enforce the security of the underlying network infrastructure and supporting protocols. In both IP-based networks and SIP-based networks, security starts by assessing, formulating, implementing and enforcing proper security baselines. Even though DoS attacks are generally very effective against QoS dependent networks, general countermeasures exist and must be exercised. Following is a list of possible countermeasures:
- Ensure proper configuration and patching of UAs, SIP Servers, user applications, and other network devices in accordance with well-established security baselines.
- Separate network domains into independent logical groups, for both media and data traffic, through the use of Virtual Local Area Networks (VLANs), which simplifies the security configuration process, rendering each group relatively immune to DoS attacks within other logical groups.
- Enable, whenever possible, port security and Media Access Control (MAC) Address filtering on all distribution switches.
- Disable, whenever possible, unnecessary services and ports in all devices that comprise the VoIP network. Deploy and enforce the concepts of Least Privilege to all the devices that comprise the VoIP Network. Also, “carefully consider the impact of blocking services that you may be using.” (Cert.org, 2003)
- Enforce, if possible, the concept of sync holes, where malicious data can be forwarded and isolated in logical groups to be analyzed, processed and discarded without adding any delays to the pertinent VoIP logical groups.
- Establish and enforce data packet filtering through the deployment of firewalls, Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPSs) on the VoIP network.
- Make sure, whenever possible, that the supporting protocols and services (i.e. TCP, UDP, NTP, SCTP, DNS, HTTP, TFTP, SNMP, TFTP, and etc…) are properly configured and dedicated to the VoIP infrastructure.
- Enable strong authentication and encrypted communications, whenever possible, on VoIP networks by activating security mechanisms such as Transport Layer Security (TLS), HTTP digest, and the Secure Real-time Transport Protocol.
- Deploy and enforce physical security, whenever possible, to all sensitive devices on the network.
- Establish and enforce proper monitoring and auditing procedures, while enabling logging as much as possible, in a logically isolated domain, to avoid adding delays to the VoIP network.
- Make sure Board Session Controllers with built-in security are deployed into the edges of the VoIP Network.
It is worth to note that there is no silver bullet when dealing with VoIP and SIP security. In fact, even though “Many international research groups, among which the IETF, are focusing their activities on VoIP security problems; at the state of art, a security standard is not available.” (Casola, Rak, Mazzeo, & Mazzoccca, 2005)
Conclusion
This paper explored the Session Initiation Protocol (SIP) and its applicability towards Voice-over-IP (VoIP) solutions, while assessing the security aspects of Denial of Service Attacks (DoS) on SIP-based systems. The evolution and current implementation details of the SIP protocol as well as the SIP architecture that supports VoIP implementations were also explored.
Since VoIP and SIP-based implementations are not much different, security wise, from other communication protocols within a computer network, they are vulnerable to almost all the same weaknesses and threats that affect any other protocol. Under this context, DoS attacks were explained and their effects were translated to the VoIP implementations. A set of guidelines to countermeasure such attacks was also provided.
The marriage between VoIP and SIP allows for an incredible set of possibilities on packet-switched telephony and the exchange of media-rich experiences. However, to realize its full potential, it is necessary to enforce the security of the underlying network infrastructure and supporting protocols. Still, there is no silver bullet in computer systems security. Only by assessing, formulating, implementing and enforcing proper security policies can the full potential of this technology flourish.
References
Casola, V., Rak, M., Mazzeo, A., & Mazzoccca, N. (2005). Security design and evaluation in a VoIP secure infrastructure: a policy based approach. Information Technology: Coding and Computing, 2005. ITCC 2005. International Conference on Volume: 1A.
Cert.org. (2003). Multiple vulnerabilities in implementations of the Session Initiation Protocol (SIP). Retrieved December 07, 2011, from
http://www.cert.org/advisories/CA-2003-06.html.
Falk, R., & Fries, S. (2008). Security Governance for Enterprise VoIP Communication. 10.1109/SECUREWARE.2008.25 IEEE. Retrieved December 08, from http://doi.ieeecomputersociety.org/10.1109/SECURWARE.2008.25.
Garuba, M., Jiang, Li, & Zhenqiang, Yi. (2008). Security in the New Era of Telecommunication: Threats, Risks and Controls of VoIP Information Technology. New Generations, 2008. ITNG 2008. Fifth International Conference.
IETF.org. (2002). Session Initiation Protocol, IETF RFC 3261. Retrieved December 08, from http://www.ietf.org/rfc/rfc3261.txt.
IETF.org. (2003). A Transport Protocol for Real-Time Applications, IETF RFC 3550. Retrieved December 06, 2011 from http://www.ietf.org/rfc/rfc3550.txt.
Nist.gov. (2005). NIST Security Considerations for Voice Over IP Systems, National Institute of Standards and Technology NIST SP 800-58. Retrieved December 09, from http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf.
Porter, Thomas, & Jr., Jan K., & Baskin, Brian. (2006). Pratical VoIP Security. Syngress : Waltham, MA.
[VoIP]
[Computer Systems Security]
[Networking]
[Internet]
Abstract
The ubiquity of the Internet has driven the development of many disrupting technologies in the last decades. Transitioning communication systems from circuit-switching to packet-switching made sense and was a natural step in the evolution of communication technology. The transmission of voice and multimedia over the global network depends on reliable and sophisticated protocols, capable of, among other things, discovering, authenticating, and linking communication endpoints. However, the excitement and demand that surrounds emerging technologies are almost always accompanied by security concerns. In this context, this research will explore the Session Initiation Protocol (SIP) and its applicability towards Voice-over-IP (VoIP) solutions, while assessing the security aspects of Denial of Service Attacks (DoS) on SIP-based systems.
SIP& VoIP: Assessing the Security Aspects of SIP-based Communications
The Internet has enabled individuals and Enterprises with instant access to all kinds of media. The now retiring traditional telephony networks are being replaced by Internet-based Voice over IP (VoIP) systems that offer equivalent, if not better, audio quality, compact and sometimes cheaper equipment, incredibly low calling prices, and innumerous extra features such as automatic call answering, call blocking, call forwarding, call waiting, fax capabilities, multi-way calling, contact lists, distinctive ringing, local number portability, voicemail, and many more. However, since data networks were not originally designed for real-time media-rich telephony services, new communication protocols and Internet standards had to be defined and enforced to enable the migration from circuit-switched to packet-switched voice transmission and conferencing services.
The need for a new standard protocol, that could enable extended interactivity through real-time media and data sharing by managing how computers find and connect to each other, pushed the creation of the Session Initiation Protocol (SIP). SIP is a signaling protocol, currently defined by the Internet Engineering Task Force (IETF) RFC 3261, capable of setting up, maintaining, and cleaning up the established sessions between computers. Other protocols exist for supporting VoIP implementations (i.e. H.323, H.248, and etc…), but they are not as simple, robust and popular as SIP, which is why SIP became the focus of this research.
SIP, however, does not support all the existing features of the VoIP systems by itself. Instead, it collaborates with many other standards (e.g. protocols, processes, and services) to accomplish this task, such as Transmission Control Protocol (TCP), Network Time Protocol (NTP), User Datagram Protocol (UDP), Stream Control Protocol (SCTP), Domain Name System (DNS), Hypertext Transfer Protocol (HTTP), Trivial File Transfer Protocol (TFTP), Simple Network Management Protocol (SNMP), Dynamic Host Configuration Protocol (DHCP), Resource Reservation Protocol (RSVP), Session Description Protocol (SDP), Real-time Transport protocol (RTP), Transport Layer Security (TLS), and etc.
This paper will describe in details how SIP supports VoIP implementations, while assessingthe security aspects of Denial of Service Attacks (DoS) in SIP-based systems.
The SIP Protocol
The dependency of the SIP protocol on other Internet processes and protocols to support VoIP applications is present since its origins. According to Porter, Jr., & Baskin (2006), the original draft for the Session Invitation Protocol (SIP v1) was submitted on February 22, 1996 to the IETF by Mark Handley and Eve Schooler.
On that same day, Henning Schulzerinne submitted to the IETF a draft specifying the Simple Conference Invitation Protocol (SCIP) – a protocol used to enable session management for point-to-point and multicast sessions.
SIPv1 – The Session Invitation Protocol
SIPv1 was text-based and used UDP as its transport protocol. It used the Session Description Protocol (SDP) as the basic mechanism to manage multimedia sessions. On SIPv1, workstations needed to be registered against an address server before sessions could be established. If the user was working remotely or in a different workstation from his own, that workstation could be temporarily registered to the address server, enabling users to establish sessions with other registered computers. However, there was no way to know if the user was available for connection establishment. If he was available, once a session was established, the work performed by SIPv1 was done. At that point, SIP v1was still very immature as a signaling protocol, accounting only for session establishment among computers. There were no conference controls available and no mechanism to tear down the sessions.
SCIP was HTTP-based and used TCP as its transport protocol allowing for both synchronous and asynchronous communications. SCIP had a more universal approach for identifying registered computers. It used e-mail address like identification instead of plain IP address as workstation identifiers within the registration servers. This allowed for greater mobility over both synchronous and asynchronous connections. It also defined a new format for handling multimedia sessions. SCIP extended beyond the session establishment by defining mechanisms to modify session parameters in active sessions. SCIP was also responsible for closing the session and “cleaning up the house” (i.e. resetting parameters and deallocating used resources) once the session was over.
SIPv2 – The Session Invitation Protocol
By the end of 1996 both the SIPv1 and SCIP protocols were merged to give birth to the Session Initiation Protocol (SIP) – also known as SIPv2. The SIPv2 protocol was HTTP-based and allowed for both UDP and TCP sessions, using SDP to describe multimedia sessions. By December 1997, to easy the work of reviewing and enhancing the protocol, the IETF decided to split SIPv2 into a basic specification and a set of extensions. By February 1999, the protocol as published for the first time as an IETF standard (RFC 2543).
RFC 3261 – The current SIP standard
On June 2002, after the review of the RFC 2543 was completed, the SIP protocol was republished as an IETF standard (RFC 3261). The new SIP protocol was based on HTTP and SMTP and used TCP, UDP, and SCTP as transport
According to IETF.com (2002), the new SIP standard was responsible for establishing, managing, and terminating multimedia sessions, among multiple computers, besides locating and inviting computers (participants) for these sessions. RFC 3261 summarizes the inner-works of the SIP protocol as follows:
"SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers…”(IETF.com, 2002)
The computers participating in a SIP session are identified by their Universal Resource Identifier (URI), based the following formats: sip:username:password@host:portfor unencrypted sessions or sips:username:password@host:portfor TLS encrypted sessions. Applications running in these computers (i.e. messaging, games, VoIP, media-rich conferences, and etc…), which depend on real-time communications can use SIP to interact and share data with each other. SIP, however, is not responsible for the actual transport of the media streams.
“The Real-time Transport Protocol RTP is an application-level protocol which is intended for delivery of delay-sensitive content, such as audio and video, through different networks.” (Falk & Fries, 2008) “The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.” (IETF.com, 2003) Thus, SIP uses the RTP protocol for transport of real-time media.
Once the SIP sessions are established, a direct virtual path, supported by the RTP protocol, is established between the endpoints of the session. This way, media is exchanged in real time through the RTP path while signaling messages are exchanged in parallel using the the SIP protocol throughout the life of the session.
Now that we learned a little bit more about the evolution of the SIP protocol and its current implementation we are ready to start investigating more deeply the protocol. To avoid any confusion among the different SIP standards, the term SIP will be used from now on to define the current version of the SIP standard, as published on IETF’s RFC 3621.
SIP and the Open Systems Interconnection Model (OSI)
The OSI model is used to describe communication protocols through a set of layers, specifying how the various protocols are capable of exchanging data among computers within a network and how the protocols relate to each other. The SIP protocol is considered as an application layer protocol. This means that user applications interact directly with the protocol to make use of its functionality.
SIP Architecture
As mentioned before, the rich set of features available through SIP to support VoIP applications is dependent on many other protocols, services, and network devices. To better understand the security vulnerabilities of the SIP protocol and VoIP applications, we need first to understand the SIP architecture.
SIP Components
Following is a brief description of the components that integrate the SIP architecture:
- User Agents (UAs): the participants of a session (i.e. software application – softphone, PDA, IP phone, connection, and etc.). UAs can communicate with other components through either client/server or peer-to-peer architectures. Each participant is equipped with the following components:
o User Agent Client (UAC): subcomponent responsible for issuing SIP requests.
o User Agent Server (UAS): subcomponent responsible for responding to UA requests.
- SIP Servers: computers capable of locating and identifying participants, besides facilitating (routing) the exchange of SIP messages among them. These servers can run in either stateless or stateful modes, caching or not all the SIP messages they process. SIP Servers can communicate with other components through either client/server or peer-to-peer architectures.
o Registrar Server: stores the UAs’ locations of the active computers on the network, based on their IP address and logged username. The registrar server also provides participant information to other servers through a service (daemon) known as Location Service.
o Proxy Server: forwards requests (SIP messages) among UAs and SIP servers. The proxy server makes use of the information stored in the Registrar servers to locate the participants and verify their statuses (i.e. online, offline, away, busy, and etc…).
o Redirect Server: redirects UACs requests to the UAs they are trying to connect to. Instead of forwarding messages as the proxy server does, the redirect server returns to the UAC the URI identification of the target UA and tell the UAC to contact the UA directly (in a peer-to-peer way). If the targeted UA is a participant registered in more than one location, the redirect server will split the session to the various UA’s locations. For example, if an UAA placed a call to a multi-location UABn (where “n” is the index of the targeted location), the phone on all the targeted UAB’s locations will ring. Only the first participant who accepted the call (for example, UAB0, UAB1, or UAB2, in the case of a participant registered in 3 different locations) will be used for the session, the other UAs will be discarded for that specific session.
IP Requests and SIP Responses
The HTTP-like characteristic of the SIP protocol allows for text-based messages that are exchanged among UAs (UACs and UASs) and SIP servers. Following is a list of the main SIP messages:
- REGISTER: used by the UAs to register both the SIP and IP addresses with the SIP Registrar Servers.
- INVITE: used to establish SIP session between UAC.
- OPTIONS: used to query the UAs capabilities (i.e. session parameters, media types to be exchanged, and etc…).
- NOTIFY: transmits information about the message’s originator UA.
- SUBSCRIBE: used to verify presence status of a specific UA (i.e. online, away, offline, available, busy, and etc…).
- ACK: used to acknowledge the exchange and correct processing of SIP messages.
- BUY: terminates a session.
- CANCEL: cancels a pending request without terminating the session.
After SIP messages are sent by either the UAs or SIP servers a response is always sent back to the message’s originator. These responses, also known as SIP responses, are grouped as follows:
- (1xx) Informational responses: informs the sender that its request was received and is being processed.
- (2xx) Success: informs the sender that its message was acknowledged and accepted.
- (3xx) Redirection: informs the sender that its message redirection may be necessary before its SIP message can be processed.
- (4xx) Client Error: informs the sender that its request was malformed and cannot be processed.
- (5xx) Server Error: Informs the sender that his request cannot be processed by one of the available SIP servers. The message may be forwarded to the next active and available server for processing retry.
- (6xx) Global Error: Informs the sender that his request cannot be processed by one of the available SIP servers. The message will not be redirected for reprocessing.
Please note that the list of specific SIP responses is huge. Thus, only the main response categories were described and the full list was omitted for brevity reasons.
Security Concerns on VoIP and SIP-based implementations
The incredible features provided by VoIP implementations far outpace the features offered by traditional circuited-switched telephony systems. However, “although VoIP was designed to be secure, VoIP technology faces many security threats nowadays.” (Garuba, Jiang,& Zhenqiang, 2008) Also, with the introduction of VOIP, “the need for security is compounded because now we must protect two invaluable assets, our data and our voice” (Nist.gov, 2005)
The dependence of VoIP on the SIP protocol and SIP extensions makes it vulnerable to most network attacks. As an application layer protocol, the SIP protocol is dependent on the lower layers of the OSI model, which makes it susceptible to any weaknesses that may affect these layers, including, among other things, Internet Protocol (IP) infrastructure vulnerabilities, operating system vulnerabilities, configuration vulnerabilities, and general network attacks. For the purposes of this research, we will focus on the effects of DoS attacks on SIP-based systems.
Denial of Service (DoS) Attacks
Denial of Service attacks are carried out by overloading the network components, in this case, UAs, SIP servers, and other network devices, with malicious traffic causing disruption of network services, degrading Quality of Service (QoS) and, occasionally, bringing down the entire network. Attacks may target any active port, through either DoS or Distributed Denial of Service (DDoS) attacks. In VoIP and SIP-based implementations, attackers may target specific ports, such as:
- 5060 port: used for non-encrypted SIP traffic for both TCP and UDP protocols.
- 5061 port: used for SIP traffic encrypted with TLS for both TCP and UDP protocols.
it is worth to note that, depending on the network configuration and branding of the network components, the port numbers may vary.
General DoS Attacks
Following is a list of some of the main DoS attacks:
- Ping Flood Attack: ports are overloaded with Internet Control Message Protocol (ICMP) Echo request packets, normally used when the attacker has more bandwidth than the victim. Targeted ports may then respond with ICMP Echo Reply packets, which consume both bandwidth and CPU cycles.
- Ping of Death (PoD) Attack: ports are overloaded with malicious traffic, crafted to ensure that packets with sizes bigger than 65,535 bytes. According to IETF.com (1981), the IP protocol (RFC 791) would be violated if a packet with such characteristics is sent through the network, unless the pack is sent in a fragmented format. Once the packet arrives on the port and is reassembled by the targeted computer, buffer overflow can occur causing the system to crash.
- Smurf Attack: this attack targets the public Internet by exploiting and flooding poorly configured network devices with maliciously crafted Internet Protocol (IP) packets. These packets are broadcasted to all linked hosts on a particular network via its broadcast address in an amplified manner, instead of targeting a specific host. This quickly consumes network bandwidth, blocking the processing of valid packets.
- SYN Flood Attack: ports listening over the TCP protocol are overloaded with crafted SYN messages, which are normally responsible for establishing the connection between a client and a server machine. Once a server receives a SYN message, it extracts the IP address of the message’s sender and prepares to establish a connection. In this case, since the sender’s address is forged, the acknowledgement message to establish the connection never returns to the server, causing it to be in a“wait” state. If too many connections are opened, the server will cease to accept connection requests for as long as the attack continues.
- Permanent DoS (PDoS) Attack: exploits security flaws of the target machines, generally embedded devices with lower internal security, to gain administrative access to its interfaces. Once access is acquired, the attacker updates the firmware of networked devices with malformed images, breaking the devices.
- Banana Attack: it overloads communication ports in targeted devices with a feedback mechanism, were outgoing traffic from the target is redirected to itself or to other devices in an out-of-sequence way, affecting and possibly disabling external access to these devices.
- Distributed Reflected DoS (DRDoS) Attack: Echo broadcast requests are crafted with a spoofed sender address, which will be the IP address of the targeted device, and sent to a huge number of computers on a poorly configured network. The computers are expected to reply to the targeted machine, flooding it and disrupting its operation. This attack is also considered as an amplification attack.
- Malware propagation: viruses and worms may cause DoS or DDoS attacks on QoS dependent networks, as a consequent burst of network traffic due to the malware’s replication and propagation efforts.
- Unintentional DoS: the targeted computer is flooded by a sudden burst of requests, as a result of unpreparedness to handle unforeseen popularity of its services due to extensive or even unexpected advertisement campaigns.
From General DoS Attacks to VoIP and SIP-based Implementations
The list of possible DoS attacks is big and its effects can be even bigger on the enterprises and individuals which businesses depend on VoIP and SIP implementations. The DoS attacks described above can be easily adapted to target the specifics of VoIP environments. To illustrate the equivalence of the general DoS attacks to VoIP, let’s consider a few examples:
- PoD Attack Targeting UA devices: as presented on the general description of the PoD attack, or Ping of Death attack, maliciously crafted data packets with sizes bigger than 65,535 bytes could be sent over UDP to the port 5060 of the UA devices (i.e. IP phones), causing them to crash.
- Malware infection on VoIP environments: since both SIP and RTP – the supporting protocol used to perform the actual exchange of real-time media streams among UAs, are extremely time-dependent (QoS dependency), a malware infection could affect the network’s quality of service by increasing the network traffic as a consequence of the malware’s replication process.
- Registrar Server Flooding Attack: by capturing and resending SIP REGISTER messages to the Registrar Servers, these servers can reach the limit of allowed registrations per second, becoming unable of registering new UAs and consequently blocking the SIP protocol from establishing new sessions for these UAs.
- Packet Replay Attack: By capturing and resending SIP packets in an out-of-sequence format an attacker can add delays to the VoIP network, affecting the quality of service. This attack is similar in many ways to the previously described Banana attack.
- DoS Attack against SIP Supporting Services: by attacking SIP supporting services (i.e. DHCP, DNC, and etc…) an attacker can affect the SIP protocol and consequently the VoIP application. For example, In a DHCP-based network, if the DHCP server is attacked and disabled, UAs and SIP Servers will become unable to exchange date, maintain, or establish sessions new sessions.
- Deceiving DoS Messages Attack: by sending valid but fake SIP messages to UAs and SIP servers, it is possible to cause busy conditions and session disconnections in the very same way DoS SYN attacks work.
- SIP Packet of Death Attack: by flooding the UAs and SIP Servers with random and out-of-sequence TCP, UDP, and ICPM packets, the VoIP network can collapse due to increased CPU usage, bandwidth consumption, and blocked services.
These are just a few examples of attacks derived from the extensive list of general DoS attacks that are used against VoIP and SIP implementation. In fact, this list does not intent, by any means, to be a complete reference.
DoS Attacks – Countermeasures
To realize the benefits of VoIP and SIP-based implementations, it is necessary to enforce the security of the underlying network infrastructure and supporting protocols. In both IP-based networks and SIP-based networks, security starts by assessing, formulating, implementing and enforcing proper security baselines. Even though DoS attacks are generally very effective against QoS dependent networks, general countermeasures exist and must be exercised. Following is a list of possible countermeasures:
- Ensure proper configuration and patching of UAs, SIP Servers, user applications, and other network devices in accordance with well-established security baselines.
- Separate network domains into independent logical groups, for both media and data traffic, through the use of Virtual Local Area Networks (VLANs), which simplifies the security configuration process, rendering each group relatively immune to DoS attacks within other logical groups.
- Enable, whenever possible, port security and Media Access Control (MAC) Address filtering on all distribution switches.
- Disable, whenever possible, unnecessary services and ports in all devices that comprise the VoIP network. Deploy and enforce the concepts of Least Privilege to all the devices that comprise the VoIP Network. Also, “carefully consider the impact of blocking services that you may be using.” (Cert.org, 2003)
- Enforce, if possible, the concept of sync holes, where malicious data can be forwarded and isolated in logical groups to be analyzed, processed and discarded without adding any delays to the pertinent VoIP logical groups.
- Establish and enforce data packet filtering through the deployment of firewalls, Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPSs) on the VoIP network.
- Make sure, whenever possible, that the supporting protocols and services (i.e. TCP, UDP, NTP, SCTP, DNS, HTTP, TFTP, SNMP, TFTP, and etc…) are properly configured and dedicated to the VoIP infrastructure.
- Enable strong authentication and encrypted communications, whenever possible, on VoIP networks by activating security mechanisms such as Transport Layer Security (TLS), HTTP digest, and the Secure Real-time Transport Protocol.
- Deploy and enforce physical security, whenever possible, to all sensitive devices on the network.
- Establish and enforce proper monitoring and auditing procedures, while enabling logging as much as possible, in a logically isolated domain, to avoid adding delays to the VoIP network.
- Make sure Board Session Controllers with built-in security are deployed into the edges of the VoIP Network.
It is worth to note that there is no silver bullet when dealing with VoIP and SIP security. In fact, even though “Many international research groups, among which the IETF, are focusing their activities on VoIP security problems; at the state of art, a security standard is not available.” (Casola, Rak, Mazzeo, & Mazzoccca, 2005)
Conclusion
This paper explored the Session Initiation Protocol (SIP) and its applicability towards Voice-over-IP (VoIP) solutions, while assessing the security aspects of Denial of Service Attacks (DoS) on SIP-based systems. The evolution and current implementation details of the SIP protocol as well as the SIP architecture that supports VoIP implementations were also explored.
Since VoIP and SIP-based implementations are not much different, security wise, from other communication protocols within a computer network, they are vulnerable to almost all the same weaknesses and threats that affect any other protocol. Under this context, DoS attacks were explained and their effects were translated to the VoIP implementations. A set of guidelines to countermeasure such attacks was also provided.
The marriage between VoIP and SIP allows for an incredible set of possibilities on packet-switched telephony and the exchange of media-rich experiences. However, to realize its full potential, it is necessary to enforce the security of the underlying network infrastructure and supporting protocols. Still, there is no silver bullet in computer systems security. Only by assessing, formulating, implementing and enforcing proper security policies can the full potential of this technology flourish.
References
Casola, V., Rak, M., Mazzeo, A., & Mazzoccca, N. (2005). Security design and evaluation in a VoIP secure infrastructure: a policy based approach. Information Technology: Coding and Computing, 2005. ITCC 2005. International Conference on Volume: 1A.
Cert.org. (2003). Multiple vulnerabilities in implementations of the Session Initiation Protocol (SIP). Retrieved December 07, 2011, from
http://www.cert.org/advisories/CA-2003-06.html.
Falk, R., & Fries, S. (2008). Security Governance for Enterprise VoIP Communication. 10.1109/SECUREWARE.2008.25 IEEE. Retrieved December 08, from http://doi.ieeecomputersociety.org/10.1109/SECURWARE.2008.25.
Garuba, M., Jiang, Li, & Zhenqiang, Yi. (2008). Security in the New Era of Telecommunication: Threats, Risks and Controls of VoIP Information Technology. New Generations, 2008. ITNG 2008. Fifth International Conference.
IETF.org. (2002). Session Initiation Protocol, IETF RFC 3261. Retrieved December 08, from http://www.ietf.org/rfc/rfc3261.txt.
IETF.org. (2003). A Transport Protocol for Real-Time Applications, IETF RFC 3550. Retrieved December 06, 2011 from http://www.ietf.org/rfc/rfc3550.txt.
Nist.gov. (2005). NIST Security Considerations for Voice Over IP Systems, National Institute of Standards and Technology NIST SP 800-58. Retrieved December 09, from http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf.
Porter, Thomas, & Jr., Jan K., & Baskin, Brian. (2006). Pratical VoIP Security. Syngress : Waltham, MA.
Defining and Comparing Mandatory Access Controls (MAC), Discretionary Access Controls (DAC) and Role-Based Access Controls (RBAC)
[Computer Systems Security]
Access controls are important components of any comprehensive IT security strategy and are used to allow or deny access to system resources through permissions and/or roles assigned to the system’s users. These controls operate in different levels and can be represented by a physical device attached to a network, a piece of software running under a OS, or even a person entrusted with the task of controlling who could access a specific resource. In computer systems security there are many forms of access controls. This paper will focus on the differences and similarities of the Mandatory Access Control (MAC), the Discretionary Access Control (DAC), and the Role-Based Access Control.
Mandatory Access Control (MAC)
In the Mandatory Access Control the security policy is determined by the operating system, not the owner of the resource. In a MAC-based system all subjects (users and processes) are tagged with security attributes that define the level of trust for accessing the system resources. Objects (system resources such as files, folders, shared memory blocks, communication ports, and etc…) are tagged as well with security attributes that define the minimum trust level required for their consumption. Thus, a subject is only allowed to access an object if his level of trust is equal or greater than the object he is trying to access. This security policy is normally managed and enforced in a centralized manner by a policy administrator. Users are not allowed to override such policy and grant access to resources that would otherwise be restricted.
Discretionary Access Control (DAC)
In the Discretionary Access Control the security policy is at the discretion of its subjects. This allows subjects, entrusted with enough permissions to assign security attributes to the objects they own. Consequently, subjects are responsible for the interactions (read, write, and execute) between their objects and other subjects.
Role-Based Access Control (RBAC)
With role-based access control, access decisions are based on the roles that individual users have as part of an organization (NIST, 1995). In this control, Roles are created to match the various job functions within an organization and its system. Then, instead of assigning permissions directly to subjects, permissions are assigned to Roles and subjects can acquire permissions only through the roles they are assigned to. Therefore, a subject can only perform actions against system resources that are authorized by his assigned active roles.
Conclusion
While MAC access control is governed by the system itself, the DAC access control is managed and enforced by the system subjects, who own their objects and can extended access to them to other subjects in the system. RBAC roles are established by an organization and its system administrators to match the job functions within the organization. These roles hold the necessary permissions that allow for the execution of their related tasks. Only through their assigned active roles can subjects perform actions against the system.
MAC is the easiest to be managed and enforced. Once security attributes are defined in the system, the system itself is responsible for their enforcement. Managing and enforcing DAC, on the other hand, is a very complex task since both subjects and objects have their very own set of permissions (besides the permissions the subjects create themselves), which can become harder to maintain and to enforce as the number of users and resources grows. DAC is also more vulnerable to malware and viruses since they could affect security policies in the same “easy” way as the system’s subjects.
On RBAC-based systems, subjects share among themselves the various roles established by the security policy. If a subject needs a different set of permissions a new role can be assigned to him or disassociated from him, without affecting the role itself or the other subjects. RBAC differs from DAC since subjects “cannot pass access permissions on to other users at their discretion.” (Ferraiolo & Kuhn, 1992) However, RBAC is similar to MAC in the sense that RBAC is “a form of mandatory access control, but it is not based on multilevel security requirements.” (DoD, 1985 )
Works Cited
DOD. (1985). Trusted Computer System Evaluation Criteria. DoD 5200.28-STD. Retrieved August 6, 2011 from: http://csrc.nist.gov/publications/history/dod85.pdf.
Ferraiolo, David F., & Kuhn, Richard. (1992). Role-based Access Control. Retrieved August 5, 2011 from: http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf.
NIST. (1995). NIST/ITL Bulletin . Retrieved on August 3, 2011 from:
http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/Intro_role_based_access.htm.
Access controls are important components of any comprehensive IT security strategy and are used to allow or deny access to system resources through permissions and/or roles assigned to the system’s users. These controls operate in different levels and can be represented by a physical device attached to a network, a piece of software running under a OS, or even a person entrusted with the task of controlling who could access a specific resource. In computer systems security there are many forms of access controls. This paper will focus on the differences and similarities of the Mandatory Access Control (MAC), the Discretionary Access Control (DAC), and the Role-Based Access Control.
Mandatory Access Control (MAC)
In the Mandatory Access Control the security policy is determined by the operating system, not the owner of the resource. In a MAC-based system all subjects (users and processes) are tagged with security attributes that define the level of trust for accessing the system resources. Objects (system resources such as files, folders, shared memory blocks, communication ports, and etc…) are tagged as well with security attributes that define the minimum trust level required for their consumption. Thus, a subject is only allowed to access an object if his level of trust is equal or greater than the object he is trying to access. This security policy is normally managed and enforced in a centralized manner by a policy administrator. Users are not allowed to override such policy and grant access to resources that would otherwise be restricted.
Discretionary Access Control (DAC)
In the Discretionary Access Control the security policy is at the discretion of its subjects. This allows subjects, entrusted with enough permissions to assign security attributes to the objects they own. Consequently, subjects are responsible for the interactions (read, write, and execute) between their objects and other subjects.
Role-Based Access Control (RBAC)
With role-based access control, access decisions are based on the roles that individual users have as part of an organization (NIST, 1995). In this control, Roles are created to match the various job functions within an organization and its system. Then, instead of assigning permissions directly to subjects, permissions are assigned to Roles and subjects can acquire permissions only through the roles they are assigned to. Therefore, a subject can only perform actions against system resources that are authorized by his assigned active roles.
Conclusion
While MAC access control is governed by the system itself, the DAC access control is managed and enforced by the system subjects, who own their objects and can extended access to them to other subjects in the system. RBAC roles are established by an organization and its system administrators to match the job functions within the organization. These roles hold the necessary permissions that allow for the execution of their related tasks. Only through their assigned active roles can subjects perform actions against the system.
MAC is the easiest to be managed and enforced. Once security attributes are defined in the system, the system itself is responsible for their enforcement. Managing and enforcing DAC, on the other hand, is a very complex task since both subjects and objects have their very own set of permissions (besides the permissions the subjects create themselves), which can become harder to maintain and to enforce as the number of users and resources grows. DAC is also more vulnerable to malware and viruses since they could affect security policies in the same “easy” way as the system’s subjects.
On RBAC-based systems, subjects share among themselves the various roles established by the security policy. If a subject needs a different set of permissions a new role can be assigned to him or disassociated from him, without affecting the role itself or the other subjects. RBAC differs from DAC since subjects “cannot pass access permissions on to other users at their discretion.” (Ferraiolo & Kuhn, 1992) However, RBAC is similar to MAC in the sense that RBAC is “a form of mandatory access control, but it is not based on multilevel security requirements.” (DoD, 1985 )
Works Cited
DOD. (1985). Trusted Computer System Evaluation Criteria. DoD 5200.28-STD. Retrieved August 6, 2011 from: http://csrc.nist.gov/publications/history/dod85.pdf.
Ferraiolo, David F., & Kuhn, Richard. (1992). Role-based Access Control. Retrieved August 5, 2011 from: http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf.
NIST. (1995). NIST/ITL Bulletin . Retrieved on August 3, 2011 from:
http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/Intro_role_based_access.htm.
Least Privilege, Separation of Duties, and Rotation of Duties
[Computer Systems Security]
Permanent high-speed connectivity to the internet has brought enormous opportunities to organizations of all sizes. Unfortunately, a connection to any network, even if temporary, increases the security risks associated to malicious software and attackers.
Permanent high-speed connectivity to the internet has brought enormous opportunities to organizations of all sizes. Unfortunately, a connection to any network, even if temporary, increases the security risks associated to malicious software and attackers.
Users are generally unaware of how real these threats are and most of them simply believe in antivirus software and firewalls as solutions capable to provide them with enough protection. While these solutions do contribute for the overall security of both home and business computers, they are only effective if part of an in-depth defense security strategy. When a user logs into a computer with administrative privileges they can alter system-wide settings that affects all users of that computer. Such actions, which can be originated from either human error (unintentional) or criminal actions (intentional), can block management software, disable firewalls and antiviruses, modify and destroy files in the computer or in file shares, format disks, and open or block communication ports, among other things, invalidating important policy settings designed to protect that device.
Programs that start under the user’s account have the same privilege as the user. The same is true for malware and viruses that are downloaded (either from the internet, file share, infected disks or thumb drives) and run under that account, compromising not only the user’s computer but also servers and other devices attached to the network. Now imagine how much damage a knowledgeable user with administrative privileges can do to an organization if he wants to do so. He may not necessarily want to bring down the company’s network or affect devices and services, but instead he may steal intellectual property and assets, impersonate other users, and after all, cover his tracks to avoid getting caught.
In such scenarios, the concepts of Least Privilege, Separation of Duties, and Rotation of Duties are invaluable tools used to minimize the security risks related to the power and trust privileges given to employees.
Least Privilege
The Department of Defense's Trusted Computer System Evaluation Criteria (DOD-5200.28STD), also known as the Orange Book, defines least privilege as principle that “requires that each subject in a system be granted the most restrictive set of privileges (or lowest clearance) needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.”
In a nutshell the idea behind this concept is to grant users only the necessary privileges to perform their tasks. This would mean that users should not be allowed to do things that are not pertinent to their jobs, such as accessing the Internet at will, listening to their preferred music or accessing photos from a compromised storage device.
This concept can be very effective if properly enforced. The risk of being affected by viruses, malicious software, human errors, and unauthorized access could be greatly minimized. Still, it is necessary to educate the users about the security threats and their consequences, otherwise, opposition to this concept may arise and its implementation becomes almost impossible to be accomplished.
Separation of Duties
This principle intends to handle conflict of interest and fraud by regulating and validating the amount of power held by the users in an organization. Management controls are specified to block the use of power for personal profit as well as collaboration among individuals for the same purpose, and to validate the correct execution of responsibilities.
Humans can and do make mistakes. They can do something incorrectly even if they have the best of intentions. And, sometimes, they may purposely perform incorrect actions. Audits are important to make sure that both users and systems are acting according to the company’s regulations. For example, Separation of Duties is applied in production and development environments to make sure that they interact as little as possible and that the installation or delivery of applications into production should be reviewed by a group of individuals other than the development group.
When effectively planned and implemented, the Separation of Duties will minimize the risk of human errors and criminal actions against the company’s assets and ensure that each individual and systems are correctly executing, and only executing, the tasks that they are responsible for.
Rotation of Duties
Rotation of Duties is closely related to the Separation of Duties concept. It can be seen as an additional deterrent to fraud. Users’ responsibilities and tasks should be rotated periodically so that it becomes more and more difficult for users to collude to exercise the complete control of any transaction for fraudulent purposes.
Also, the rotation of responsibilities allows for exchange of experiences and cross-training among employees, besides improving the depth or personnel skills and succession.
Conclusion
Organizations are constantly faced with internal and external threats in a world where the need to stay connected is an increasingly addiction. Computer users, who are ever more familiarized with the Internet but remain mostly unaware of its security risks, are entrusted with power and access to computer and networks in their work environment. Bad practices, human errors, and criminal acts are transforming employees in the biggest security threat to their organization’s computer systems.
In this posting, security principles were researched to address this situation. Among them were the concepts of Least Privilege, Separation of Duties, and Rotation of Duties.
Least Privilege mitigates the risks associated with administrative accounts by granting users only the rights necessary to carry out their jobs.
Separation of Duties intends to handle conflict of interest, the appearance of it, and fraud by regulating and validating the amount of power held by the users in an organization.
Rotation of duties extends the principle of Separation of Duties as a mean of identifying fraud by periodically rotating responsibilities among the individuals within an organization. It also promotes employees personal growth by allowing for the diverse sharing of experiences and cross-training.
When combined and well implemented, those principles contribute to the computer system security by specifying the individual tasks for each of the employees within an organization, the minimum necessary privileges to allow then to perform their tasks, mechanisms of control and validation for such tasks, besides allowing for the employees individual growth.
Works Cited
NIST (1996). Trusted Computer System Evaluation Criteria – The Orange Book. Retrieved July 8, 2011, from http://csrc.nist.gov/publications/history/dod85.pdf
Security systems: The weakest link in establishing access control
[Computer Systems Security]
As I have pointed out in my previous post, the human factor represents the biggest threat to computer systems security. It is also my personal belief that it represents the weakest link in establishing access control within the enterprise. This is due to the fact that humans are responsible for the creation, implementation, enforcement, audition, maintenance and usage of all security policies as well as the systems that are supposed to be protected by these policies. Even though users are expected to comply with their organization's security policy, which dictate the users' acceptable actions and responsibilities in respect to computer systems, they regularly violate such policy by performing actions that negatively affect the integrity, availability, and confidentiality of such systems and their data.
While most organizations focus their security efforts on software and hardware layers, this is, in most cases, an expensive and somewhat ineffective way to deal with the problem. Of course, having good security software and hardware helps to protect systems and their assets, but it is not an enough solution by itself. “Your organization can be bristling with firewalls and IDS, but if a naïve user ushers an attacker in through the back door you have wasted your money” (Power, p.18).
If managers and system administrators cannot enforce, maintain, and properly audit security policies and access control mechanisms, the security of the computer systems is compromised. Also, developers, who should strive to achieve a balance between security and simplicity on their applications, normally fail to do so, creating complex systems, hard to configure and use, and consequently doomed to security vulnerabilities. Users, on the other hand, are, in most cases, technically challenged and careless while interacting with computer systems, which end up being exposed through either accidental or intended misuse of access. “All it takes is just one weak link in the chain for an attacker to gain a foothold into your network” (Nichol, p.1).
Krutz, Ronald L., Russell Dean Vines. The CISSP Prep Guide. New York: John Wiley & Sons, Inc., 2001. 1 – 26.
Nichol, Kelly. “Implementing a Security Awareness Training Program in Your Environment for Every Day Computer Users.” 18 Dec. 2000. URL: http://www.giac.org/paper/gsec/381/implementing-security-awareness-training-program-environment-day-computer-user/100982
As I have pointed out in my previous post, the human factor represents the biggest threat to computer systems security. It is also my personal belief that it represents the weakest link in establishing access control within the enterprise. This is due to the fact that humans are responsible for the creation, implementation, enforcement, audition, maintenance and usage of all security policies as well as the systems that are supposed to be protected by these policies. Even though users are expected to comply with their organization's security policy, which dictate the users' acceptable actions and responsibilities in respect to computer systems, they regularly violate such policy by performing actions that negatively affect the integrity, availability, and confidentiality of such systems and their data.
While most organizations focus their security efforts on software and hardware layers, this is, in most cases, an expensive and somewhat ineffective way to deal with the problem. Of course, having good security software and hardware helps to protect systems and their assets, but it is not an enough solution by itself. “Your organization can be bristling with firewalls and IDS, but if a naïve user ushers an attacker in through the back door you have wasted your money” (Power, p.18).
If managers and system administrators cannot enforce, maintain, and properly audit security policies and access control mechanisms, the security of the computer systems is compromised. Also, developers, who should strive to achieve a balance between security and simplicity on their applications, normally fail to do so, creating complex systems, hard to configure and use, and consequently doomed to security vulnerabilities. Users, on the other hand, are, in most cases, technically challenged and careless while interacting with computer systems, which end up being exposed through either accidental or intended misuse of access. “All it takes is just one weak link in the chain for an attacker to gain a foothold into your network” (Nichol, p.1).
Works Cited
Krutz, Ronald L., Russell Dean Vines. The CISSP Prep Guide. New York: John Wiley & Sons, Inc., 2001. 1 – 26.
Nichol, Kelly. “Implementing a Security Awareness Training Program in Your Environment for Every Day Computer Users.” 18 Dec. 2000. URL: http://www.giac.org/paper/gsec/381/implementing-security-awareness-training-program-environment-day-computer-user/100982
The greatest risk to computer systems
[Computer Systems Security]
It is not news that the human factor is the greatest risk to computer systems. In fact, a multitude of researchers have been pointing to this conclusion for at least a few decades now (Colleman 2011). It does not matter if it is a virus, a malware, a phishing attack, a faked website, a true hacking action, a sorry mistake, or even an accident. Behind each one of these actions there will always be a person.
It could be a careless user trying to download some free content from his home computer, a distracted employee who forgot to follow his company’s policy, an individual determined to hurt the organization who laid him off (The McCart Group 2011), or a criminal hacker who wants to make money by selling any information or secret he may steal.
The fact is humans are as unpredictable as the motives that drive them to commit such actions, which makes it very hard for any computer system or organization to monitor them and react properly against security breaches.
Think about it… How easy is it for someone to make a mistake? It happens all the time, right? Now, how hard is it to hack into the Pentagon? Very hard (at least I hope so). It takes a lot of effort and preparation to pursue such attack, and even worst, to cover all the tracks and leave the system undetected after the attack is over. As you may see, no matter how small or how big the damage is, the human factor is undoubtedly the major player behind such actions.
Still, to me, as a software developer, there is more to it than just the human factor. There is also the “computer factor”! Please, let me explain myself. I do agree that humans are the medium through which the “thought of an attack” could become a real threat. But it does not seem right to just label people as security threats. In my opinion, computers and computer systems are pieces of a complex puzzle which is still evolving and has not matured yet to harmoniously interact with humans, and vice-versa. Human behavioral patterns should be taken in consideration whiles designing computers and computer systems.
The computer world and everything that supports it is a work in progress and it seems that much time was spent formulating the machine rules, its electronics and the miniaturization of its components, its architecture, its computer languages, its management environment (which we call the operating system) with the purpose of making it ever more easy-to-use, mobile, powerful, faster, and scalable.
Computers are fascinating devices indeed. However, not nearly as much time was spent trying to understand the effects of the human-computer in the sense of self-aware computing. In fact, studies such as the Computer Self-Efficacy: Development of Measure and Initial Test (Compaeu & Higgins 1995), Self-Aware Distributed Systems (Rish, Beygelzimer, Tesauro, & Das 2004), and Self-Aware Computing (Agarwal, Miller, Eastep, Wentziaff, & Kasture 2009) are still considered science-fiction by most computer scientists.
Humans are in control and aware of their actions and needs. Data is just an abstraction unaware of its own context, purpose, and lifecycle. If the knowledge gained from such studies could be translated to computer systems security and If data could be made aware of its own context and usability, maybe it could "defend itself" against improper use and contribute to its own integrity throughout its lifecycle (usage) on computer systems. This would allow for more adaptive, self-healing, goal-oriented, efficient, resilient, and easy to program and to maintain systems.
Humans do represent the biggest risk to computer systems security. However, the lack of studies in human-computer and computer-human interaction towards self-aware computing is the main reason why computer systems are so vulnerable.
In a cyber-world, where the governing laws are all about sophisticated abstractions (objects) of our physical world, data is just a static model, unaware of its purpose and incapable to react to its users’ actions.
We try to protect the castle by adding layers and layers of hardware and software around the data. But once the data is outside of a safe environment it just becomes a defenseless prey.
If data could be made aware of its context and integrity mechanisms could be embedded into its abstractions (i.e. a file, a group of files, a data stream, and etc…), computer systems could become more adaptive, self-healing, goal-oriented, efficient, resilient, and easy to program and to maintain.
Compeau, Deborah R., & Higgins, Chriostopher A. (1995) Computer Self-Efficacy: Development of Measure and Initial Test. Retrieved from: http://www.jstor.org/pss/249688
Rish, Irina, & Beygelzimer, Alina, & Tesauro, Gerry, & Das, Rajarshi. (2005). Self-Aware Distributed Systems. Innovation Matters. Retrieved from http://domino.watson.ibm.com/comm/research.nsf/pages/r.ai.innovation.2.html
Agarwal, Awant, & Miller, Jason, & Eastep, Jonathan, & Wentziaff, David, & Kasture, Harshad. (2009). Self-Aware Computing. Massachussets Institute of Technology. Retrieved from: http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA501367
Colleman, Kevin. (2011). Digital Conflict. Retrieved from http://defensesystems.com/blogs/cyber-report/2011/07/human-vulnerability-computer-systems.aspx
The McCart Group. (2011). Disgruntled Employees – A Cyber Risk.. Retrieved from http://www.mccart.com/Webs/_Base/Default/uploadedFiles/documents/Newsletter%20Articles/January/Disgruntled%20Employees%20-%20A%20Cyber%20Risk.pdf
It is not news that the human factor is the greatest risk to computer systems. In fact, a multitude of researchers have been pointing to this conclusion for at least a few decades now (Colleman 2011). It does not matter if it is a virus, a malware, a phishing attack, a faked website, a true hacking action, a sorry mistake, or even an accident. Behind each one of these actions there will always be a person.
It could be a careless user trying to download some free content from his home computer, a distracted employee who forgot to follow his company’s policy, an individual determined to hurt the organization who laid him off (The McCart Group 2011), or a criminal hacker who wants to make money by selling any information or secret he may steal.
The fact is humans are as unpredictable as the motives that drive them to commit such actions, which makes it very hard for any computer system or organization to monitor them and react properly against security breaches.
Think about it… How easy is it for someone to make a mistake? It happens all the time, right? Now, how hard is it to hack into the Pentagon? Very hard (at least I hope so). It takes a lot of effort and preparation to pursue such attack, and even worst, to cover all the tracks and leave the system undetected after the attack is over. As you may see, no matter how small or how big the damage is, the human factor is undoubtedly the major player behind such actions.
Still, to me, as a software developer, there is more to it than just the human factor. There is also the “computer factor”! Please, let me explain myself. I do agree that humans are the medium through which the “thought of an attack” could become a real threat. But it does not seem right to just label people as security threats. In my opinion, computers and computer systems are pieces of a complex puzzle which is still evolving and has not matured yet to harmoniously interact with humans, and vice-versa. Human behavioral patterns should be taken in consideration whiles designing computers and computer systems.
The computer world and everything that supports it is a work in progress and it seems that much time was spent formulating the machine rules, its electronics and the miniaturization of its components, its architecture, its computer languages, its management environment (which we call the operating system) with the purpose of making it ever more easy-to-use, mobile, powerful, faster, and scalable.
Computers are fascinating devices indeed. However, not nearly as much time was spent trying to understand the effects of the human-computer in the sense of self-aware computing. In fact, studies such as the Computer Self-Efficacy: Development of Measure and Initial Test (Compaeu & Higgins 1995), Self-Aware Distributed Systems (Rish, Beygelzimer, Tesauro, & Das 2004), and Self-Aware Computing (Agarwal, Miller, Eastep, Wentziaff, & Kasture 2009) are still considered science-fiction by most computer scientists.
Humans are in control and aware of their actions and needs. Data is just an abstraction unaware of its own context, purpose, and lifecycle. If the knowledge gained from such studies could be translated to computer systems security and If data could be made aware of its own context and usability, maybe it could "defend itself" against improper use and contribute to its own integrity throughout its lifecycle (usage) on computer systems. This would allow for more adaptive, self-healing, goal-oriented, efficient, resilient, and easy to program and to maintain systems.
Conclusion
Humans do represent the biggest risk to computer systems security. However, the lack of studies in human-computer and computer-human interaction towards self-aware computing is the main reason why computer systems are so vulnerable.
In a cyber-world, where the governing laws are all about sophisticated abstractions (objects) of our physical world, data is just a static model, unaware of its purpose and incapable to react to its users’ actions.
We try to protect the castle by adding layers and layers of hardware and software around the data. But once the data is outside of a safe environment it just becomes a defenseless prey.
If data could be made aware of its context and integrity mechanisms could be embedded into its abstractions (i.e. a file, a group of files, a data stream, and etc…), computer systems could become more adaptive, self-healing, goal-oriented, efficient, resilient, and easy to program and to maintain.
Works Cited
Compeau, Deborah R., & Higgins, Chriostopher A. (1995) Computer Self-Efficacy: Development of Measure and Initial Test. Retrieved from: http://www.jstor.org/pss/249688
Rish, Irina, & Beygelzimer, Alina, & Tesauro, Gerry, & Das, Rajarshi. (2005). Self-Aware Distributed Systems. Innovation Matters. Retrieved from http://domino.watson.ibm.com/comm/research.nsf/pages/r.ai.innovation.2.html
Agarwal, Awant, & Miller, Jason, & Eastep, Jonathan, & Wentziaff, David, & Kasture, Harshad. (2009). Self-Aware Computing. Massachussets Institute of Technology. Retrieved from: http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA501367
Colleman, Kevin. (2011). Digital Conflict. Retrieved from http://defensesystems.com/blogs/cyber-report/2011/07/human-vulnerability-computer-systems.aspx
The McCart Group. (2011). Disgruntled Employees – A Cyber Risk.. Retrieved from http://www.mccart.com/Webs/_Base/Default/uploadedFiles/documents/Newsletter%20Articles/January/Disgruntled%20Employees%20-%20A%20Cyber%20Risk.pdf
Subscribe to:
Posts (Atom)