What sets out procedures and guidelines for dealing with security incidents?

Begin by Talking About the Issue

Before you even start to write policy, find some people and discuss what you want to achieve. Talk about the trade-offs:

Could the policy be more liberal or stricter?

Could it be more specific or more liberal?

There are two principal reasons to do this:

The aim is to get buy in from the stakeholders. Asking people's opinion before sending them a draft allows you to determine the views of others and also to demonstrate that you care about their opinion and want their feedback. This gets people involved.

By discussing the policy out loud, you begin to collate the concepts into a logical readable issue.

The Use of the English Language in Policy Should Be Simple

Policy should be simple. For most organizations it should be targeted somewhere between 6th and 9th grade mastery of the English language.

Overly wordy policies with impressive sounding words are commonly misunderstood.

Keep the language used in writing policy Simple!

Policy Should Be Evaluated on Clarity and Conciseness

When you are evaluating policy, assess it from the perspective of the consumer. In this case this is the individual who needs to read, understand, and follow the policy.

The policy simply has to be clear and concise.

If users start to read something they do not understand, they tend to go on to something else.

Information Security Procedures

Procedures can be defined as a particular course or mode of action. They describe an act or manner of proceedings in any action or process. The procedures explain the processes required in requesting USERIDs, password handling, and destruction of information. The procedures for requesting USERIDs or access changes will be conducted in the future via E-mail with easy to use templates that prompt the requester for all the information required. Requests can be expedited in a matter of minutes providing greater productivity for all concerned.

The Information Security Procedures can be described as the “action manual”. It contains the following sections on how to.

USERIDs Request Procedures This section outlines in detail the steps required to request access to the system or, change access or suspend/delete access. There are clear easy to follow steps with diagrams of the panels you will encounter and instructions on how to complete the different fields. There are individual sections on good password procedures, reporting breaches of security and how to report them.

Personnel Security Procedures This section outlines personnel security procedures for hiring, induction, termination and other aspects of dealing with information security personnel issues.

Disposal of Sensitive Waste The disposal of sensitive waste is indeed a high profile one at the moment especially in light of recent stories in the popular press. It is amusing to see what is on the back of the reused computer paper that comes out of the kindergarten.

11.2.10 Identify data security procedures

Data security functions and procedures must be identified that protect confidential or classified information. Information security is a profession that addresses a broader range of computer security and information assurance challenges. Data security represents a subset of the information security capabilities that will be performed by the software product. Information security means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording, or destruction. Software engineering involves the establishment of logical controls that monitor and regulate access to sensitive (confidential or classified) information. Information security functions must be identified and the appropriate procedures defined for:

Access control, including user account administration, identification, authentication, and authorization. Access control protects information by restricting the individuals who are authorized to access sensitive information.

Information security classification, involving the identification of different data classification levels, the criteria for data to be assigned a particular level, and the required controls to govern the access to each level of sensitive information.

Cryptography, including information encryption and decryption.

Security Measurement Process

The security measurement process described in Special Publication 800-55 comprises two separate activities—security measure development and security measure implementation. During security measure development system owners and information security program managers determine relevant measures and select measures appropriate for the state of the security program or the information system. The selection of security measures considers organizational strategic goals and objectives, mission and business priorities, security and information resources requirements, and the operational environments in which information systems are deployed. Agencies also need to ensure that the appropriate technical and functional capabilities are in place before initiating security measurement, including mechanisms for data collection, analysis, and reporting. The process of developing security measures, illustrated in Figure 5.2, first identifies and defines measurement requirements and then selects the set of measures that will satisfy those requirements. Because security measurement and performance management are iterative processes, the type of measures implemented and the specific metrics used to measure performance change over time, as the organization matures its security measurement practices and as it gains new information through the collection of performance data.

The identification of security measurement needs depends in part on ensuring that the process includes all relevant stakeholders and represents their interests. Senior organizational leaders with management or oversight responsibility for information security, information resources management, or risk management are obvious candidates to participate in security measure definition, along with common control providers and information system owners, program managers and business process owners, security officers, and personnel responsible for implementing or operating security controls. Stakeholder interests typically differ depending on the roles and responsibilities stakeholders have, their level within the organization structure, and the employees, users, or program beneficiaries or service consumers they represent. Some stakeholder responsibilities may correspond to needs for particular measures that provide a function—or domain-specific perspective on information security performance. The information security program should encourage stakeholder participation throughout the process of security measure development to validate the applicability of the measures selected. The type of measures selected—implementation, effectiveness and efficiency, or impact—also typically vary by stakeholder, as senior leaders may be more interested in impact and efficiency measures while system owners and operational security personnel typically emphasize implementation and effectiveness measures [38]. Agencies identify and document information security goals and objectives and security requirements that guide security control implementation for individual information systems and for the organizational information security program. Sources considered in this part of the process include agency, information technology, and security strategic plans, performance plans, policies, laws, regulations, and associated guidance. With respect to FISMA requirements, FIPS 200 specifies minimum security requirements for information systems categorized at different impact levels [39], corresponding to required security controls selected from Special Publication 800-53. Security controls selected for implementation and documented in information system security plans provide a key source of implementation measures, as system owners and information security program managers have an interest in verifying the proper implementation of selected measures to achieve adequate security protection for their information systems.

Organizational security policies and procedures often include implementation details specifying how different security controls should be implemented based on security control and control enhancement descriptions in Special Publication 800-53 and security objectives for each control defined in Special Publication 800-53A. This guidance provides valuable input to the development of security measures and determinations of the most appropriate methods to use to measure security control performance. Agencies should also identify existing metrics and sources of data potentially useful in measuring program-level or system-level security performance, including information in system security plans, risk assessment reports, security assessment reports, plans of action and milestones, inspector general audit reports, and continuous monitoring reports. Selected information security measures may address the security performance of specific security controls, groups of related or interdependent controls, an information system, or security function, service, or program spanning multiple systems. Agencies typically development and implement measures focused on different aspects of security and with different scope to cover all relevant performance objectives, aggregating measures or measurement perspectives to provide and organizational view of information security performance. The set of measures with potential applicability security performance drivers and objectives is typically large and diverse. To overcome the challenges comprehensive measurement would present, agencies need to prioritize performance objectives and implemented measures to ensure that selected measures provide appropriate coverage for security controls and information systems categorized at higher risk levels.

Tip

Agencies and their system owners have widely varying experience developing and implementing information security performance measures. NIST lists candidate performance measures in Special Publication 800-55 [40], providing sample measures for each security control family and indicating the type of measure (implementation, effectiveness and efficiency, or impact) and whether the measures apply at the program or system level. Agencies can use these same measures as a guide to developing security measures for their own systems and information security programs to help ensure that the set of measures selected includes all types and addresses all relevant areas of performance.

Establishing performance targets is also an important element of defining and implementing information security measures. Performance targets establish a set of objectives against which agencies can measure success. Using initial security measurement results as a baseline for performance, agencies can use initial and current measurement values and performance targets to track progress towards achieving security objectives. Different performance targets typically apply to different types of measures—implementation measure performance targets often reflect full implementation (such as “100%” on a quantitative scale, “implemented” or “complete” on an ordinal scale) while targets for effectiveness and efficiency measures and impact measures are often stated as relative improvements sought at each measurement interval or as the attainment of specific performance levels driven by business objectives.

Paging procedure in LTE

Another issue among security procedures of LTE arises when the network pages a UE. The paging process is as follows: there are different modes like active and idle for the UE. When the UE is in the idle mode, it disconnects itself from the base station. Suppose the connection should be re-established with an idle subscriber as a result of a voice call initiation. The base station broadcasts a paging message within the user’s tracking area which consists of several cells. This paging message contains a set of temporary IDs since the base station pages several users at a time. The temporary ID that is included in the paging message is the TMSI which provides pseudonymity of the UEs [TAT 13]. Once the user hears its TMSI, it will change its state to active and respond to the call.

Considering this preceding procedure, suppose that an adversary is the one who initiated the call and sent the request to the base station. Then, the attacker monitors the paging channel to obtain the set of TMSIs that have been paged by base station within the user’s tracking area. Since there are several TMSIs within a single paging message, the attacker initiates the same call several times. Therefore, continuing this procedure would result in obtaining several sets of TMSIs for the attacker. At this point, intersecting those identities could yield the TMSI of the intended user. The procedure is shown in Figure 11.5. It is worth mentioning that TMSI will not be changed within certain tracking area and that the paging messages are not encrypted. Changing the tracking area by the user would lead to obtaining a new TMSI. Thus, performing the same attack enables an adversary to also track the location of the subscriber as well.

Note that in commercial networks, it would be expensive for an attacker to perform this attack, and the result would simply be the temporary identity of one regular subscriber. In PSN, this regular subscriber is a first responder. Therefore, the consequences of this particular attack may be crucial.

To ensure privacy during the paging procedure, a physical layer approach is proposed in [TAT 13]. The authors use a function with the UE’s temporary ID as input and a tag as output. During the paging period of a subscriber, instead of transmitting TMSI, the corresponding tag would be inserted. However, any correlation among the tags for different users should not exist. An interesting point is that the transmission power of the signal needs not to be at such a level that the receiver could decode it. The receiver should only be able to detect the signal to be able to ensure if she/he has been paged or not. This results in saving energy. This scheme is also beneficial in terms of downlink bandwidth conservation. Despite the efficiencies of this approach, one drawback of it is the need to change the physical layer procedure that would lead to changing the hardware, which might be costly.

7.5.3 Evolved Packet Core

This CN has at least five components: the MME, the home subscriber server (HSS), the SGW, the PDNGW, and the PCRF gateway.

The MME handles the security procedures (user authentication, ciphering, and integrity protection), the terminal/network sessions including identification and collection of idle channels. The user subscriber (ID and addressing) information and the user profile information in HSS are invoked via the S6 interface. Any radio path ciphering and integrity information specific to the user is also stored in the HSS. The SGW links the packet data to the E-UTRAN. It serves as an anchor node for data transfer point until the next handover. The PDNGW links the packet data to the PDN. Packet filtering and virus-infected packets are removed from the network at this gateway. Finally, the policy decision function (PDF), charging rules function (CRF) are housed in the PCRF server. Additional constraints may also be temporarily interjected by this server.

Personnel Security (PS)

PS-1Personnel Security Policy and ProceduresControl Requirement:The organization develops, disseminates, and reviews/updates at least annually:a.

A formal, documented personnel security policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

Formal, documented procedures to facilitate the implementation of the personnel security policy and associated personnel security controls.

NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook.

NIST SP 800-100, Information Security Handbook: A Guide for Managers.

PS-2Position CategorizationControl Requirement:The organization:a.

Assigns a risk designation to all positions;

Establishes screening criteria for individuals filling those positions; and

Reviews and revises position risk designations at least every three years.

C.F.R. 731.106(a), Designation of public trust positions and investigative requirements—Risk Designation.

PS-3Personnel ScreeningControl Requirement:The organization:a.

Screens individuals prior to authorizing access to the information system; and

Rescreens individuals according to the following conditions:

For national security clearances; a reinvestigation is required during the 5th year for top secret security clearance, the 10th year for secret security clearance, and 15th year for confidential security clearance.

For moderate risk law enforcement and high impact public trust level, a reinvestigation is required during the 5th year. There is no reinvestigation for other moderate risk positions or any low risk positions.

5 C.F.R. 731.106, Designation of public trust positions and investigative requirements.

FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems.

FIPS Publications 201, Personal Identity Verification (PIV) of Federal Employees and Contractors.

NIST SP 800-73, Interfaces for Personal Identity Verification (4 Parts)—Pt. 1- End Point PIV Card Application Namespace, Data Model & Representation; Pt. 2- PIV Card Application Card Command Interface; Pt. 3- PIV Client Application Programming Interface; Pt. 4- The PIV Transitional Interfaces & Data Model Specification.

NIST SP 800-76, Biometric Data Specification for Personal Identity Verification.

NIST SP 800-78, Cryptographic Algorithms and Key Sizes for Personal Identification Verification (PIV) ICD 704, Personnel Security Standards and Procedures Governing Eligibility for Access and other Controlled Access Program Information to Sensitive Compartmented Information.

PS-4Personnel TerminationControl Requirement:The organization, upon termination of individual employment:a.

Terminates information system access;

Conducts exit interviews;

Retrieves all security-related organizational information system-related property; and

Retains access to organizational information and information systems formerly controlled by terminated individual.

PS-5Personnel TransferControl Requirement:The organization reviews logical and physical access authorizations to information systems/facilities when personnel are reassigned or transferred to other positions within the organization and initiates JAB approved and accepted service provider defined transfer or reassignment actions within five days.References:

PS-6Access AgreementsControl Requirement:The organization:a.

Ensures that individuals requiring access to organizational information and information systems sign appropriate access agreements prior to being granted access; and

Reviews/updates the access agreements at least annually.

PS-7Third-Party Personnel SecurityControl Requirement:The organization:a.

Establishes personnel security requirements including security roles and responsibilities for third-party providers;

Documents personnel security requirements; and

Monitors provider compliance.

NIST SP 800-35, Guide to Information Technology Security Services.

PS-8Personnel SanctionsControl Requirement:The organization employs a formal sanctions process for personnel failing to comply with established information security policies and procedures.References:

AP-ADVICE-SETUID-01

Create procedures to review and document all requests to setuid programs.

The company's HP NonStop Server Security Procedures should include the following instructions for managing setuid requests for in-house programs:

The request for setuid should include a full explanation of the program's purpose and a justification of the use of privileged procedures.

The system manager or a trusted programmer must review the program's function.

Management must approve the setuid in writing with authorized signature(s).

To ensure that the source code matches the actual object program, the system manager, not the developer, should compile and bind the final program.

The program must be tested to ensure that it does not perform or allow any actions that would be considered security violations. This test is usually performed by the security staff.

The above document should be maintained in a file for future reference by auditors.

Requests for setuiding user programs may be allowed if the following conditions are met:

The function is legitimate and necessary.

The function cannot be achieved using nonprivileged programming techniques.

Secure setuid'd programs so that only authorized users can execute them.

7.3.4 Trusted and Untrusted Non-3GPP Accesses

3GPP has also defined required security procedures for UEs that connect to the EPC using a non-3GPP access. As mentioned in Chapter 6, 3GPP has defined two classes of accesses, or rather two types of procedures, for how to connect a UE to EPC via a non-3GPP access: trusted non-3GPP accesses and untrusted non-3GPP accesses. The definition of these two types of non-3GPP accesses is a common source of confusion. It should, however, be noted that whether a specific non-3GPP access network is considered as trusted or untrusted is only indirectly related to the access technology itself. It is rather the operator that decides whether it wants to treat a particular non-3GPP access network as trusted or untrusted. In a roaming scenario, it is the home operator that decides. This could, for example, mean that a particular non-3GPP access network (e.g. a WLAN network) is considered trusted by one operator but untrusted by another operator, even though the security properties of the network are the same for both operators. It may instead be that the operators have different preferences when it comes to how a 3GPP UE should connect to EPC via that network. As described in Chapter 6, connectivity solutions using IPsec tunnels are used in untrusted non-3GPP networks, while connectivity solutions for trusted non-3GPP networks, rely on the connectivity solutions native to the particular access technology without additional secure tunneling from the UE.

The description for when a non-3GPP access is considered as trusted was recently updated and is described in TS 33.402 as: “When all of the security feature groups provided by the non-3GPP access network are considered sufficiently secure by the home operator, the non-3GPP access may be identified as a trusted non-3GPP access for that operator. However, this policy decision may additionally be based on reasons not related to security feature groups.” The description of when to consider a non-3GPP access as untrusted is described in the same specification as: “When one or more of the security feature groups provided by the non-3GPP access network are considered not sufficiently secure by the home operator, the non-3GPP access may be identified as an untrusted non-3GPP access for that operator. However, this policy decision may additionally be based on reasons not related to security feature groups.”

In the following sections we will look more closely at the access security in trusted and untrusted non-3GPP accesses.

What sets out procedures and reporting guidelines for dealing with security incidents?

What are the principal types and configuration options?

What refers to logical security technologies designed to prevent malicious software from running on a host?

When a computer security incident occurs it is recommended that the organization not reveal all they know in public forums?