IT Security Management , Risk

Unit7

Management and Security Auditing

IT Security Management
• IT SECURITY MANAGEMENT: A process used to achieve and maintain
appropriate levels of confidentiality, integrity, availability, accountability,
authenticity, and reliability. IT security management functions include:
• determining organizational IT security objectives, strategies, and policies
• determining organizational IT security requirements
• identifying and analyzing security threats to IT assets within the organization
• identifying and analyzing risks
• specifying appropriate safeguards
• monitoring the implementation and operation of safeguards that are necessary in
order to cost effectively protect the information and services within the organization
• developing and implementing a security awareness program
• detecting and reacting to incidents
Plan: Establish security policy, objectives, processes and procedures;
perform risk assessment; develop risk treatment plan with appropriate
selection of controls or acceptance of risk.
Do: Implement the risk treatment plan.
Check: Monitor and maintain the risk treatment plan.
Act: Maintain and improve the information security risk management
process in response to incidents, review, or identified changes.
Organization Context and Security Policy
• Identify organization’s IT security objectives, strategies, and policies in the context of the organization’s general risk profile.
• Given the organizational security objectives and strategies, an organizational security policy is developed that describes what the
objectives and strategies are and the process used to achieve them
• The organizational or corporate security policy may be either a single large document or, more commonly, a set of related
documents.
• The scope and purpose of the policy
• The relationship of the security objectives to the organization’s legal and
• regulatory obligations, and its business objectives
• IT security requirements in terms of confidentiality, integrity, availability, accountability, authenticity, and reliability, particularly with regard to the
views of the asset owners
• The assignment of responsibilities relating to the management of IT security and the organizational infrastructure
• The risk management approach adopted by the organization
• How security awareness and training is to be handled
• General personnel issues, especially for those in positions of trust
• Any legal sanctions that may be imposed on staff, and the conditions under which such penalties apply
• Integration of security into systems development and procurement
• Definitionoftheinformationclassificationschemeusedacrosstheorganization
• Contingency and business continuity planning
• Incident detection and handling processes
• How and when this policy should be reviewed
• The method for controlling changes to this policy
• Security policies are different for different oraganization like IBM, Microsoft, Apple etc.
Security Risk Assesment
• A Security Risk Assessment (or SRA) is an assessment that involves
identifying the risks in your company, your technology and your processes
to verify that controls are in place to safeguard against security threats.
• formal standards that detail suitable IT security risk assessment
processes, including [ISO13335], [ISO27005], and [NIST12]. In particular,
[ISO13335] recognizes four approaches to identifying and mitigating risks
to an organization’s IT infrastructure:
1. Baseline approach
2. Informal approach
3. Detailed risk analysis
4. Combined approach
Baseline Approach
• The baseline approach to risk assessment aims to implement a basic general level of security
controls on systems using baseline documents, codes of practice, and industry best practice.
• Advantage are that it does not require the expenditure of additional resources in conducting a
more formal risk assessment and that the same measures can be replicated over a range of
systems
• Disadvantage is that no special consideration is given to variations in the organization’s risk
exposure based on who they are and how their systems are used
• Also, there is a chance that the baseline level may be set either too high, leading to expensive
or restrictive security measures that may not be warranted, or set too low, resulting in
insufficient security and leaving the organization vulnerable.
• Suitable baseline recommendations and checklists may be obtained from a range of
organizations, including:
• Various national and international standards organizations
• Security-related organizations such as the CERT, NSA, and so on 􏰁 Industry sector councils or peak groups
Informal Approach
• The informal approach involves conducting some form of informal, pragmatic risk
analysis for the organization’s IT systems.
• This analysis does not involve the use of a formal, structured process, but rather exploits
the knowledge and expertise of the individuals performing this analysis.
• These may either be internal experts, if avail- able, or, alternatively, external consultants.
• Advantage is that the individuals performing the analysis require no additional skills.
Hence, an informal risk assessment can be performed relatively quickly and cheaply.
• Disadvantage the approach is informal, the results may be skewed by the views and
prejudices of the individuals performing the analysis. It may also result in insufficient
justification for suggested controls, leading to questions over whether the proposed
expenditure is really justified.
• The use of the informal approach would generally be recommended for small to
medium-sized organizations where the IT systems are not necessarily essential to
meeting the organization’s business objectives and where additional expenditure on risk
analysis cannot be justified.
Detailed Risk Analysis
• using a formal structured process, this provides the greatest degree of assurance
that all significant risks are identified and their implications considered.
• This process involves a number of stages, including identification of assets,
identification of threats and vulnerabilities to those assets, determination of the
likelihood of the risk occurring and the consequences to the organization should
that occur, and hence the risk the organization is exposed to.
• Advantage are that it provides the most detailed examination of the security risks
of an organization’s IT system, and produces strong justification for expenditure
on the controls pro- posed. It also provides the best information for continuing to
manage the security of these systems as they evolve and change.
• Disadvantage is the significant cost in time, resources, and expertise needed to
perform such an analysis.
Combined Approach
• combines elements of the baseline, informal, and detailed risk analysis approaches
• aim is to provide reasonable levels of protection as quickly as possible, and then to examine and adjust
the protection controls deployed on key systems over time
• The approach starts with the implementation of suitable baseline security recommendations on all
systems. Next, systems either exposed to high risk levels or critical to the organization’s business
objectives are identified in the high-level risk assessment. A decision can then be made to possibly
conduct an immediate informal risk assessment on key systems, with the aim of relatively quickly tailoring
controls to more accurately reflect their requirements. Lastly, an ordered process of performing detailed
risk analyses of these systems can be instituted. Over time this can result in the most appropriate and
cost-effective security controls being selected and implemented on these systems.
• Advantage, The use of the initial high-level analysis to deter- mine where further resources need to be
expended, rather than facing a full detailed risk analysis of all systems, may well be easier to sell to
management.
• If the initial high-level analysis is inaccurate, then some systems for which a detailed risk analysis should
be performed may remain vulnerable for some time. And maintained minimum security because of using
baseline approach
• Risk Index = Max Info Sensitivity - Min User Clearance
Indentification of Threats/
Risks/Vulnerbilities
• Asset: A system resource or capability of value to its owner that requires
protection.
• Threat: A potential for a threat source to exploit a vulnerability in some
asset, which if it occurs may compromise the security of the asset and
cause harm to the asset’s owner.
• Vulnerability: A flaw or weakness in an asset’s design, implementation,
or operation and management that could be exploited by some threat.
• Risk: The potential for loss computed as the combination of the
likelihood that a given threat exploits some vulnerability to an asset, and
the magnitude of harmful consequence that results to the asset’s owner.
Analysis Risks:
• Analysis of risk is done using quantitative and qualitative approach
• Risk = (Probability that threat occurs) * (Cost to organization)
Security Auditing:
• Security auditing is a form of auditing that focuses on the security of
an organization’s information system (IS) assets. This function is a key
element in computer security. Security auditing can:
• Provide a level of assurance concerning the proper operation of the computer
with respect to security.
• Generate data that can be used in after-the-fact analysis of an attack, whether
successful or unsuccessful.
• Provide a means of assessing inadequacies in the security service.
• Provide data that can be used to define anomalous behavior.
• Maintain a record useful in computer forensics.
Security Auditing Architecture
• ITU-T2 Recommendation X.816 develops a model that shows the elements of the security
auditing function and their relationship to security alarms. Figure 18.1 depicts the model.
The key elements are as follows:
• Event discriminator: This is logic embedded into the software of the system that monitors system
activity and detects security-related events that it has been configured to detect.
• Audit recorder: For each detected event, the event discriminator transmits the information to an audit
recorder. The model depicts this transmission as being in the form of a message. The audit could also
be done by recording the event in a shared memory area.
• Alarm processor: Some of the events detected by the event discriminator are defined to be alarm
events. For such events an alarm is issued to an alarm processor. The alarm processor takes some
action based on the alarm. This action is itself an auditable event and so is transmitted to the audit
recorder.
• Security audit trail: The audit recorder creates a formatted record of each event and stores it in the
security audit trail.
• Audit analyzer: The security audit trail is available to the audit analyzer, which, based on
a pattern of activity, may define a new auditable event that is sent to the audit recorder
and may generate an alarm.
• Audit archiver: This is a software module that periodically extracts records from the
audit trail to create a permanent archive of auditable events.
• Archives: The audit archives are a permanent store of security-related events on this
system.
• Audit provider: The audit provider is an application and/or user interface to the audit
trail.
• Audit trail examiner: The audit trail examiner is an application or user who examines the
audit trail and the audit archives for historical trends, for computer forensic purposes,
and for other analysis.
• Security reports: The audit trail examiner prepares human-readable security reports.
Security Auditinhg Functions
• Data generation: Identifies the level of auditing, enumerates the types of auditable events, and identifies the minimum
set of audit-related information provided. This function must also deal with the conflict between security and privacy and
specify for which events the identity of the user associated with an action is included in the data generated as a result of
an event.
• Event selection: Inclusion or exclusion of events from the auditable set. This allows the system to be configured at
different levels of granularity to avoid the creation of an unwieldy audit trail.
• Event storage: Creation and maintenance of the secure audittrail. The storage function includes measures to provide
availability and to prevent loss of data from the audit trail.
• Automatic response: Defines reactions taken following detection of events that are indicative of a potential security
violation.
• Audit analysis: Provided via automated mechanisms to analyze system activity and audit data in search of security
violations. This component identifies the set of auditable events whose occurrence or accumulated occurrence indicates
a potential security violation. For such events, an analysis is done to determine if a security violation has occurred; this
analysis uses anomaly detection and attack heuristics.
• Audit review: As available to authorized users to assist in audit data review. The audit review component may include a
selectable review function that provides the ability to perform searches based on a single criterion or multiple criteria
with logical (i.e., and/or) relations, sort audit data, and filter audit data before audit data are reviewed. Audit review may
be restricted to authorized users.
Implementation guidelines
• The ISO3 standard Code of Practice for Information Security Management (ISO 27002)
provides a useful set of guidelines for implementation of an auditing capability:
• Audit requirements should be agreed with appropriate management.
• The scope of the checks should be agreed and controlled.
• The checks should be limited to read-only access to software and data.
• Access other than read-only should only be allowed for isolated copies of system files, which
should be erased when the audit is completed or given appropriate protection if there is an
obligation to keep such files under audit documentation requirements.
• Resources for performing the checks should be explicitly identified and made available.
• Requirements for special or additional processing should be identified and agreed.
• All access should be monitored and logged to produce a reference trail; the use of timestamped
reference trails should be considered for critical data or systems.
• All procedures, requirements, and responsibilities should be documented.
• The person(s) carrying out the audit should be independent of the activities audited.
Security Audit Trail
• A set of records that collectively provide documentary evidence of processing
used to aid in tracing from original transactions forward to related records and
reports, and/or backwards from records and reports to their component source
transactions.
• categories for audit trail design
• SYSTEM-LEVEL AUDIT TRAILS :System-level audit trails are generally used to monitor and
optimize system performance but can serve a security audit function as well.
• APPLICATION-LEVEL AUDIT TRAILS :Application-level audit trails may be used to detect
security violations within an application or to detect flaws in the application’s interaction
with the system.
• USER-LEVEL AUDIT TRAILS: A user-level audit trail traces the activity of individual users
over time. It can be used to hold a user accountable for his or her actions.
•
Implementation the Logging Functions
• approaches to implementing the logging function for system-level and user-level
audit trails on the one hand and application-level audit trails on the other.
• Logging at the System Level: Much of the logging at the system level can be implemented
using existing facilities that are part of the operating system.
• WINDOWS EVENT LOG:
• An event in Windows Event Log is an entity that describes some interesting occurrence in a
computer system. Events contain a numeric identification code, a set of attributes (task,
opcode, level, version, and keywords), and optional user-supplied data. Windows is equipped
with three types of event logs:
• System event log: Used by applications running under system service accounts (installed system services),
drivers, or a component or application that has events that relate to the health of the computer system.
• Application event log: Events for all user-level applications. This log is not secured and it is open to any
applications. Applications that log extensive information should define an application-specific log.
• Security event log: The Windows Audit Log. This event log is for exclusive use of the Windows Local
Security Authority. User events may appear as audits if supported by the underlying application.
• Windows allows the system user to enable auditing in nine different
categories:
• Account login events
• Account management
• Directory service access
• Logon events
• Object access
• Policy changes
• Privilege use
• Process tracking
• System events