Scribd
Upload
47 views5 pages

UNIT 7 - IT Security Management Risk Assessment Security Auditing5 Hrs

The document discusses information security management and provides details about organizational security policies, security risk assessment, security risk analysis, and implementing logging functions for security auditing. It defines key terms and outlines the purpose and components of security policies, the steps in a security risk assessment model, and examples of events that should be logged for auditing.

Uploaded by

tiwarisapana036
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
47 views5 pages

UNIT 7 - IT Security Management Risk Assessment Security Auditing5 Hrs

The document discusses information security management and provides details about organizational security policies, security risk assessment, security risk analysis, and implementing logging functions for security auditing. It defines key terms and outlines the purpose and components of security policies, the steps in a security risk assessment model, and examples of events that should be logged for auditing.

Uploaded by

tiwarisapana036
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

"The ones who are crazy enough to think they

can change the world, are the ones who do."

INSO

Unit-7

IT Security Management, Risk Assessment & Security


Auditing(5 hrs)
What is information security management?
Information security management describes the set of policies and procedural controls that
IT and business organizations implement to secure their informational assets against threats
and vulnerabilities. Many organizations develop a formal, documented process for managing
InfoSec, called an information security management system, or ISMS.

8.3. Organizational Security Policies

A key element of any organization's security planning is an effective security policy. A


security policy must answer three questions: who can access which resources in what
manner?

A security policy is a high-level management document to inform all users of the goals of
and constraints on using a system. A policy document is written in broad enough terms
that it does not change frequently. The information security policy is the foundation upon
which all protection efforts are built. It should be a visible representation of priorities of
the entire organization, definitively stating underlying assumptions that drive security
activities. The policy should articulate senior management's decisions regarding security
as well as asserting management's commitment to security. To be effective, the policy
must be understood by everyone as the product of a directive from an authoritative and
influential person at the top of the organization.

People sometimes issue other documents, called procedures or guidelines, to define how
the policy translates into specific actions and controls. In this section, we examine how to
write a useful and effective security policy.

Purpose
Security policies are used for several purposes, including the following:

recognizing sensitive information assets


clarifying security responsibilities
promoting awareness for existing employees
guiding new employee

Security Risk Assessment:


Definition

A security risk assessment identifies, assesses, and implements key security


controls in applications. It also focuses on preventing application security defects
and vulnerabilities. Carrying out a risk assessment allows an organization to view
the application portfolio holistically—from an attacker’s perspective. It supports
managers in making informed resource allocation, tooling, and security control
implementation decisions. Thus, conducting an assessment is an integral part of an
organization’s risk management process.

The 4 steps of a successful security risk


assessment model
1. Identification. Determine all critical assets of the technology infrastructure.
Next, diagnose sensitive data that is created, stored, or transmitted by these
assets. Create a risk profile for each.
2. Assessment. Administer an approach to assess the identified security risks for
critical assets. After careful evaluation and assessment, determine how to
effectively and efficiently allocate time and resources towards risk mitigation.
The assessment approach or methodology must analyze the correlation
between assets, threats, vulnerabilities, and mitigating controls.
3. Mitigation. Define a mitigation approach and enforce security controls for each
risk.
4. Prevention. Implement tools and processes to minimize threats and
vulnerabilities from occurring in your firm’s resources.

Security Risk Analysis:


Risk analysis identifies and analyzes the potential impact that could adversely
affect key business initiatives or projects. This process is performed to help
organizations avoid or mitigate those risks.

The different types of risk analysis include considering the possibility of adverse
events caused by natural disasters, such as severe storms, earthquakes or floods;
or adverse events caused by malicious or accidental human activities. An essential
part of risk analysis is identifying the estimated damage from these events and the
likelihood of their occurrence.

What Is the Difference Between Risk Analysis and


Risk Assessment?
As we explain in our article risk assessment versus risk analysis, there is a critical
distinction between risk assessment and risk analysis. Risk assessment is a larger
process where all potential threats are considered. During the risk analysis
process, the level of each risk is determined. Both fall under the broader umbrella
of risk management tools.

An organization should conduct various risk assessments, to identify all potential


hazards. A cybersecurity risk assessment is just one of those numerous
assessments, and all of them include risk analysis as a crucial step.

Security Auditing Architecture:


An information security audit is an audit of the level of information security in an organization. It is an
independent review and examination of system records, activities, and related documents. These audits
are intended to improve the level of information security, avoid improper information security designs, and
optimize the efficiency of the security safeguards and security processes. Within the broad scope of
auditing information security there are multiple types of audits, multiple objectives for different audits,
etc. Most commonly the controls being audited can be categorized as technical, physical
and administrative. Auditing information security covers topics from auditing the physical security of data
centers to auditing the logical security of databases, and highlights key components to look for and
different methods for auditing these areas.

Here are some more specific benefits to running security audits.

Verify that your current security strategy is adequate or not

Check that your security training efforts are moving the needle from one audit to the next

Reduce cost by shutting down or repurposing extraneous hardware and software that you
uncover during the audit

Security audits uncover vulnerabilities introduced into your organization by new technology
or processes

Prove the organization is compliant with regulations – HIPAA, SHIELD, CCPA, GDPR, etc.

Security Audit Trials:


An audit trail (also called audit log) is a security-relevant chronological record, set of
records, and/or destination and source of records that provide documentary evidence
of the sequence of activities that have affected at any time a specific operation,
procedure, or event.

The audit trail includes all or some of the following:

Application-specific audit trail – ideally, each application records business-relevant events.


They may be logged in text files or in separate database tables. They allow reconstructing the
history much better than the arbitrary noisy logging that is usually in place

Application logs – this is a broader category as it includes logs that are not necessarily part of
the audit trail (e.g. debug messages, exception stack traces). Nevertheless, they may be
useful, especially in case there is no dedicated application-specific audit trail functionality

Database logs – whether it is logged queries, change data capture or change tracking
functionality, or some native audit trail functionality

Operating system logs – for Linux that would include the /var/log/audit/audit.log (or similar
files), /var/log/auth.log. For Windows, it would include the Windows Event logs for the
Security and System groups.

Access logs – access logs for web servers can be part of the audit trail especially for internal
systems where a source IP address can more easily be mapped to particular users.

Network logs – network equipment (routers, firewalls) generate a lot of data that may be seen
as part of the audit trail (although it may be very noisy)

Implementing Logging Function:


Log events in an audit logging program should at minimum include:

1. Operating System(OS) Events


start up and shut down of the system
start up and down of a service
network connection changes or failures
changes to, or attempts to change, system security settings and controls
2. OS Audit Records
log on attempts (successful or unsuccessful)
the function(s) performed after logged on (e.g., reading or updating critical file,
software installation)
account changes (e.g., account creation and deletion, account privilege assignment)
successful/failed use of privileged accounts
3. Application Account Information
successful and failed application authentication attempts
application account changes (e.g., account creation and deletion, account privilege
assignment)
use of application privileges
4. Application operations
application startup and shutdown
application failures
major application configuration changes
application transactions, for example,
e-mail servers recording the sender, recipients, subject name, and attachment
names for each e-mail
Web servers recording each URL requested and the type of response provided
by the server
business applications recording which financial records were accessed by each
user

The details logged for each event may vary widely, but at minimum each event should
capture

timestamp
event, status, and/or error codes
service/command/application name
user or system account associated with an event
Device used (e.g. source and destination IPs, terminal session ID, web browser etc.)

It’s not faith


in technology.
It’s faith in people
using technology.
INSO

You might also like