You are on page 1of 34

Aujas IS-IM Framework Maturity Measure

What is an "Information Security - Incident Management" Maturity Model ?

A quantifiable measurement that can be used to track the progress in achieving the desired level of maturity of an information s
with CoBIT, ISO 27035 and NIST 800-83 standard as a base for guidance. The measurement is done in line with CoBIT framew

Metrics are something observed or calculated that is used to show the presence or state of a condition or trend; this model will
People, Process and Technology for Monitoring, Prevention against malicious Code and Networking.

How are Maturity Metrics and Measurement of Maturity defined?

Maturity and Metrics Measurement Model is defined from baseline information and domains of CoBIT, ISO 27035 and CMM. Th

How
Whatare Maturity
is the Metrics
defintion andinMeasurement
defined Maturity? of Maturity defined?

The table below depicts the maturity model for incident management. It is divided into 4 broad areas -
1. Information Security Incident Management Governance - Define Roles and Responsibilities, Cross Functional Teams, In
measuring or reporting incident metrics including Trending.
2. Incident Management Process - Process definition, detailed procedures for managing incident across its lifecycle.
3. Incident Management Technology - Measuring threat preparedness via point tools, early indicators, monitoring and maturit
4. Incident Management People Readiness- Skills, Role Definition, Policy Awareness and Mock Preparedness via Testing.

Description
Rating

Governance - There exist no defined teams for information security incident response, roles and res
need for managing information security incidents, and no measurable actions taken to address the
0 - Non-Existent People - No competency defined, training not provided and R&R is not made aware about, right set
Process- Does not exist and is addresed ad-hoc with existing capabilities
Technology - Basic technology for protection but no proactive monitoring of events and alerts

The organization has recognized that there is a need to respond and evaluate incidents. An Inciden
1 - Initial
solutions exist like Perimeter Security and Log Monitoring but no proactive monitoring, correlation a

Incident Plan is documented, but response is inconsistent, eradication is the focus, but no postmort
2 - Repeatable process has evolved to a point where a few key individuals are responsible for managing the inform
however, the process remains unstructured, informal and mostly reactive. technology controls for w

Incident Response Plan is documented, repeatable, and postmortem learning is documented, but s
3 - Defined Technology solutions are matured and addresses all the areas of threats mitigation. SIEM is implem
mitigation, Zero day vulnerability, security analytics and rapid response arrangements to address se

A comprehensive Incident Response Program is in place, tested routinely, and postmortem is cond
integration with proper law enforcement has been established.
The process is well linked with other governance function.
4 - Managed
Technology solutions monitor advanced indicator of compromise, all critical assets and threats to th
correlated in SIEM. Security threats are subscribed and incident response process is automated. M
governance bodies
A dedicated team of knowledgeable and trained incident response professionals are part of the form
active incident and they execute a methodical strategy to identify the source, root causes, and they
5 - Optimized protocols.
Most systems have been equipped with automatic detection and warning mechanism, which are co
All point tools are working in an integrated manner and leveraged to identify security attacks in adva
rk Maturity Measurement

vel of maturity of an information security incident management. The maturity model is build inline
is done in line with CoBIT framework of measurement.

ondition or trend; this model will mesure the maturity of IS-IM across five domains - Governance,
orking.

CoBIT, ISO 27035 and CMM. The maturity model is based on CoBIT.

areas -
ties, Cross Functional Teams, Interaction Model, Coordination, Policy, approval and Training and

dent across its lifecycle.


ndicators, monitoring and maturity of preventive and detective technology controls.
ock Preparedness via Testing.

Description

y incident response, roles and responsibilities are not defined and there is basic awareness of the
ble actions taken to address the requirements.
not made aware about, right set of people to respond to incidents not identified
bilities
itoring of events and alerts

nd evaluate incidents. An Incident Plan may partially exist, but not repeatable. Point technology
roactive monitoring, correlation and threat mitigation and response exist.

tion is the focus, but no postmortem analysis is done and no training is provided. The resolution
ponsible for managing the information security incidents. Information is shared among staff;
eactive. technology controls for web, email and host protection exists.

em learning is documented, but scope is contained to quick eradication.


hreats mitigation. SIEM is implemented and logs are correlated But advanced persistent threat
onse arrangements to address security incident does not exist.

outinely, and postmortem is conducted. Forensic evidence is properly collected for analysis and

all critical assets and threats to them are identified, Logs of all critical assets are monitored and
sponse process is automated. Metrics are defined and moniotred periodically and reported to
professionals are part of the formal Incident Response Program. The team is able to monitor an
he source, root causes, and they pursue eradication and containment based on established risk

arning mechanism, which are continuously tracked and evaluated.


o identify security attacks in advance and proactive response is ensured.
Domains
1. IS-IM Governance (Policy / Procedure/ Reporting / R&R,
Metrics and Audit)
2. IS-IM Process (Process / Procedure/ Templates)
3. People (Training, Awareness, JDs/Staffing / Response
arrangement)

4. Technology - Monitoring (IS-IM technology controls for


detection and response/ reporting and measurement)

4. Technology - Malicious Code (IS-IM technology


controls for detection and response/ reporting and measurement)

4. Technology - Network (IS-IM technology controls for


detection and response/ reporting and measurement)
H2 - 2018 H1 - 2019
1.42 2.35

2.46 3.07

2.13 3.00

2.24 2.76

2.70 2.93

2.97 3.12

0.99 Between 0 and 1


1.99 Between 1 and 2
2.99 Between 2 and 3
3.99 Between 3 and 4
DOMAIN RATING
Aujas Networks - Information Security Incident Management's Maturity Assessment
Information Gathering - Process - Information Security Incident Management's

S. No. Tool

Management Commitment / Approval, Monitoring and Reporting Source

There exists an documented and approved information security incident


1.01 management policy and processes with defined purpose and clear NIST 80-061
objectives, roles and responsibilities and reporting

The IS-IM policy, Process and procedure documents are approved by


1.02 ISO27001
the Management

The IS-IM policy and process documents are communicated with all the
1.03 stakeholders and awareness conducted to various stakeholders for NIST 80-061
handling information security incident

An ISIRT charter is defined to address scope, limitations,


1.04 communication and interaction, authority and responsibility to manage ISO 27001
information security incidents

Incident reporting mechanism is established for reporting of information


1.05 security events and Communication plan is established to contact NIST 80-061
specific individual during incident

There exists approved guidelines for communicating with outside


1.06 NIST 80-061
parties regarding incidents

1.07 Evidence management system is defined and established NIST 80-061

Management has selected a team structure and staffing model for


1.08 NIST 80-061
incident response team

1.09 There exists an roadmap for maturing the incident response capability NIST 80-061

All Critical / High priority information security incidents are reviewed by


1.1 NIST 80-061
Management in the governance meetings
Identified deficiencies are reported to management after root cause
1.11 NIST 80-061
analysis is completed

Management authorizes adequate action to close the identified findings


1.12 NIST 80-061
in order to reduce the occurrence frequency of incidents

1.13 Escalation matrix is defined and established NIST 80-061

There exists a defined mechanism to identify the operational


1.14 consequence of incident scenarios in terms of (Severity and Impact) ISO 27005

Roles and Responsibilities


Roles and responsibilities have been established by the management
2.01 to ensure a quick, effective, and orderly response to information
security incidents. ISO 27001

2.02 Management has ensured that necessary criterion has been identified NIST 80-061
for personnel to fill a defined role

2.03 NIST 80-061


Determining what services the ISIRT (information security incident
response) team should provide is documented

2.04 NIST 80-061


Interaction model between various teams is defined and appraised off
Training and End user awareness

3.01 Necessary trainings are provided to ISIRT members based on their


roles NIST 80-062
3.02
Annual dry run is performed to test the preparedness RSA - Best Practices

3.03 Management has ensured that formal training conducted for all
employees, contractors ISO 27001
Metrics
4.01 Information security incident management KPIs and metrics are defined ISO 27001

Information Security Incident Management's Reports have been


4.02
identified and published periodically to management
ISO 27001
4.03 KPI are reviewed and updated periodically ISO 27001
Incident Reports
There are approved format to prepare and report information security
5.01 incident management across its lifecycle with capability to track each
action item and decision ISO 27001

Information security incident reports are reviewed and approved by the


5.02
management personnel with learning's incorporated
ISO 27001
1.42 2.35
t

Observation Before IS-IM


Maturity Maturity Response post IS-IM Program
Program

0 to 5 0 to 5

An IS-IM procedure existed with


clear objectives but not with
detailed roles and responsibilities A detailed roles and responsibilities with
2 3
and mechanism to report and clear interaction model is defined
track information security
incidents
VP-CA approved the process and VP-CA approved the process and
3 3
procedure for IS-IM procedure for IS-IM
The IS-IM had certain groups like
ISIRT charter, members identified
Training is provided to ISIRT members
2 but no training and awareness 3
and R&R awareness created
provided to the required
stakeholders.

1 ISIRT charter does not exist 2 ISIRT charter created

There is no specific mechanism Reporting mechanism defined to


established to report information Helpdesk / email and contact but
2 2
security incident, it is primarily via automation of incident and tracking should
emails to ISO / CISO be done as a part of further phase

The existing process provides The guidelines, criteria, approval and


1 guidelines for escalating it to 2 notification template has been defined in
CERT IS-IM project
There is no evidence
0 management (collection, chain of 2 Evidence Management is defined
custody etc) defined

ISIRT team has been mentioned ISIRT team is leveraged and improved
2 2
and members identified further by R&R definitions

A roadmap for the maturity of IS-IM


No roadmap for maturity is
1 2 framework, its automation and technology
defined
control is identified
The "Critical and High" priority
The "Critical and High" priority incidents
incidents destined to be
destined to be escalated and discussed
1 escalated and discussed with 1
with Management as defined in the
Management as defined in the
procedure
procedure
RCA of incidents to be conducted
and reported to the Management RCA procedure defined, forensic process
as a part of the procedure, but no established, reporting template defined
1 2
fixed template and timeline and communication and timelines
defined to report security incident identified
with RCA and lesson's learned

Defined in the procedure,


1 2
however the process is ad-hoc
Escalation matrix defined with timelines
2 Escalation matrix defined 3
and template for notification

A detailed classification criteria


A detailed classification criteria for
2 for information security incidents 3
information security incidents exist
exist

Roles and responsibilities are


Detailed R&R and interaction model and
2 defined but not detailed for all 3
their respective role has been defined
stakeholders
Pre-requisite for the roles has not
1 3 Pre-requisite has been defined
been defined

Authority, limitation, role and Authority, limitation, role and


2 communication is not defined in 3 communication is defined in detail for
detail for ISIRT team members ISIRT team members

Model defined but not detailed Detailed R&R and interaction model and
2 3
with R&R and notification their respective role has been defined

Training needs and formal


1 2 Training identified and planned
training is not provided
Planned to be executed Mid-February
0 Planned but never executed 2
2014
Default policy and procedure
Specific training and awareness material
1 covers part of information 2
planned to be provided periodically
security incident management

1 No KPIs defined 2 KPIs are defined in the framework


Same status, however incident will
Dashboard contain incidents,
2 3 contain more details and defined KPIs
tracking via an excel sheet
populated
1 KPIs are not populated 2 KPIs defined and can be populated

Reporting and escalation format Reporting formats and notification


1 2
do not exist templates defined

Information Security incident


Same status, however incident will
reports and actions are reviewed
2 2 contain more details and defined KPIs
via dashboard and periodic
populated
meetings
DOMAIN RATING
Aujas Networks - Information Security Incident Management's Maturity Assessment
Information Security Incident Management - Maturity Assessment
S. No. Tool
The Information Security Incident Management's Process Source

The incident management process document exists, approved by


1.01 NIST 80-083
management and communicated to the relevant stakeholders

1.02 The "Incident Identification" process activity is specified NIST 80-083

1.03 The "Incident logging" process activity is specified NIST 80-083

1.04 The "Incident categorisation" process activity is specified NIST 80-083

1.05 The "Incident Prioritisation" process activity is specified NIST 80-083

1.06 The "Initial Diagnosis/ Validation" process activity is specified NIST 80-083

1.07 The "Incident Escalation" process activity is specified NIST 80-083

1.08 The "Investigation and Forensic" process activity is specified NIST 80-083

1.09 The "Recovery" process activity is specified NIST 80-083

1.1 The "Incident Closure" process activity is specified NIST 80-083

1.11 Timescales are defined for all incident handling stages NIST 80-083

1.12 Incident Manager/Process Owner is defined NIST 80-083

Incident Models are defined (for Various types of systems such as Corporate
1.13 NIST 80-083
Information Systems, ICS, SCADA)

Incident tracking is defined with templates for notification and reporting


1.14 NIST 80-083
defined
1.15 Data entered into incidents at all stages is checked for completeness NIST 80-083

1.16 Incident Management Process review procedure is in place NIST 80-083

Incident Logging - Service Desk

2.01 The Service Desk function is defined for logging information security incidents ISO 27035

The Service Desk is aware of their role at Tier 1/Level 1 Information Security
2.02 ISO 27035
Incident Management logging and updating status

Knowledge Bases are in place to support Incident Resolution at the Service


2.03 ISO 27035
Desk for known solutions
2.04 Workarounds are documented in the Knowledge Base ISO 27035

Information Security Incident Management's Process Interactions

Interaction models defined for other relevant stakeholders like CERT,


3.01 NIST 80-083
Management, BCP, ERT etc.

Information sharing format and template identified and documented for


3.02 NIST 80-083
sharing with internal and external stakeholders

3.03 Integration with Change Management (post implementation reviews) ISO 27035

Incident Records and Reporting and Communication


Incident Identification
4.01 ISO 27035
Can Incident records be created manually? Or automated
Unique Reference
4.02 Does the tool automatically allocate a unique reference to newly created ISO 27035
records at the time of opening the record?
Date and Time
4.03 Is each Incident record date and time stamped when created and again each ISO 27035
time the record is updated?

Source of the Incident


4.04 Does each Incident record contain a field or fields to record the identity of the ISO 27035
source of reporting of the Incident (such as event trigger, person or group)?

Contact Details
4.05 Does each incident record contain a field or fields to record the contact ISO 27035
information and call back method such as telephone or email?

Incident Symptoms
4.06 Does each Incident record contain a field or fields to describe the symptoms ISO 27035
of the fault? This can include event parameters and user reported symptoms.

Incident Status
4.07 Does the Incident record contain a field or fields to record the status of the ISO 27035
incident (such as active, waiting, closed)?
Incident Categorization and Prioritization
4.08 Does the Incident record contain category and priority fields to record the type ISO 27035
and impact of Incident ?
Incident Assignment
4.09 Does the Incident record contain a field or field(s) to assign the incident to a ISO 27035
support department, group or individual?
Incident Resolution and Closure
4.1 Do the Incident records have a field or fields to record Resolution Information ISO 27035
including resolution date and time?
Management Reports
4.11 ISO 27035
Does the tool produce reports from record detail captured?
Record Sharing
Does the process details the sharing of incident record and report with internal
4.12 and external parties like Management, other governance bodies, CERT and NIST 80-083
Rapid Response teams
2.46 3.07
t

Maturity Observation Before IS-IM Program Maturity


0 to 5 0 to 5

Process is document and approved by


2 Management, however not communicated 3
and trained to all relevant stakeholder

Incident identification is specified and


2 2
detailed with verification and roles

Incident logging post declaration is


2 2
specified

Incident categorization based on multiple


2 2
parameter is identified
Prioritization is based on criticality and is
2 2
appropriate

2 Incident Validation is specified 3

2 Incident escalation is identified 3

Incident investigation activity was defined


2 3
but no procedure mentioned

2 Incident recovery process is defined 3

Incident closure and lessons learned


2 2
activity is defined

Timescales for categorization defined,


1 2
escalation and mobilization is not defined

2 ISIRT chair will own the incident 2


Assets affected is covered as a part of
2 incident and its impact on categorization 2
and prioritization'
Tracking is dine via excel sheet for all
2 3
reported incidents
2 Validation is done and reported 2
Periodic review, minimum once in a year
2 2
is defined

Information security incidents are logged


2 3
and tracked via excel sheet

Training for categorisation / information


1 collection and information dissemination is 2
not provided

1 2
KB does not exist
Known workarounds are documented for
IT incident, some overlapping with
1 security incidents like virus cleaning / 2
update failure etc / there is no separate
DB for KB

Interaction model is not appropriate with


2 3
detailed R&R and notification

1 Templates were not documented 2

Changes lead by learning's of incidents


2 are ad hoc but follow a change 3
management procedure

2 Incident identification is manual 3

2 All incident have Unique reference 2

Date is mentioned and timestamp


2 3
provides exact timing of the incident

2 Source is identified 3

2 Names identified with email addressed 2

Symptoms identified but not detailed with


2 chronology of information security 3
incidents

2 Yes, it contains the status 3

Yes, with categorization and prioritization


2 3
is defined

2 Incident assignment is manual and ad hoc 3

Incident resolution / recovery and closure


2 3
is identified as a part of procedure

2 Reporting is ad-hoc 3

Record sharing is identified with internal


2 3
and external stakeholder
Response post IS-IM Program

Process and procedure is updated with additional


details like rapid response, interaction, R&R and
communicated to ISIRT and other relevant
stakeholders
Incident identification is specified and detailed with
verification and roles
Recommended is to automate logging of incident in
a tool via service desk and in future automated via
some GRC tool
All parameters are covered for categorization of
information security incidents
Prioritization is based on criticality and is
appropriate
No change suggested, however detailed validation
procedure are specified
Notification and escalation template have been
added

Incident investigation procedure is defined

Detailed procedure with top 5 threats have been


defined

No change suggested

Timescales for all escalation and stages defined

No change suggested

No change suggested

Information security incidents will be more detailed


covering all phases providing deep dive
Validation is done and reported

Periodic review, minimum once in a year is defined

Logging is proposed via automated tool

Proposed is the training and customization to log


incident with categorization and prioritization and
workflow for information dissemination and
escalation

Proposed
Proposed is to build a detailed solution and
implementation of lessons learned for information
security incidents

Interaction mode is defined in detailed with separate


R&R and notification/ information handover

Templates are documented for information sharing


with internal and external stakeholders

Changes lead by learning's of incidents are formally


defined and will be followed and reported

Proposed is automated incident identification and


logging

No change suggested

Proposed is automated tool, which will register


timestamp for incident logging

Source identification is detailed with more


information / with information of incident from
systems collected

Names identified with email addressed

Revised procedure documents full chronological


incidents

Yes, the revised template contains the status

Yes, with categorization and prioritization is defined

Proposed is to have appropriate team with


mobilization and addressing based on requirement

Incident resolution / recovery and closure is


identified as a part of procedure and is detailed

Periodic reporting with details is proposed in


updated procedure

Further templates with desired fields and data


documented for sharing with internal and external
stakeholders
DOMAIN RATING
Aujas Networks - Information Security Incident Management's Maturity Assessment
Information Gathering - Process - Information Security Incident Management's
S. No. Tool
The Information Security Incident Management's Process Source
General

Does Security Monitoring covers all critical assets logs for incidents?
1.01 NIST 80-083

Does monitoring coverage is 24*7


1.02 ISO 27001

Are events and alerts and correlation rules derived from Business
1.03 ISO 27001
requirements, risk assessment and threat profiles

Scope
How many correlations rules are configured in the SIEM and are all rules
2.01 created are built-in or Customized based on threat profile ISO 27001

Device coverage is comprehensive for all critical assets of ICS

2.02 ISO 27001

Which are the standards to which this implementation adheres to? E.g. ADSIC
2.03 compliance etc, Is the reporting automated ISO 27001
Is the SIEM integrated with incident management ? Are workflows implemented
2.04 for various level of escalations based on criticality and priority ? ISO 27001

Operations
Please describe the incident classification categories and its handling by
separate qualified professional like L1, L2, L3 ?
3.01 ITIL V3

Administrator activities being logged on all the systems being monitored


3.02 ITIL V3

Does the sources of logs have all detailed logged like logins, client IP, server IP
3.03 and source program information. ITIL V3
Are time frames defined for escalating alerts?
3.04 ITIL V3
Different priority of events generated and confirmed for incidents
3.05 ITIL V3

Integration (Sharing of data amongst other Infosec tools)


Is the solution integrated with other systems, like ticketing
4.01 ITIL V3

How is the data shared between the integrated systems


4.02 ITIL V3

Reporting / Governance / SLA


Defined SLA for Collection and Coverage (% of event sources covered = ISO 27001 / CoBIT
5.01 (Number of event sources from which log data is captured/Number of IT 5.0 / ITIL V3
components deployed within the data centres) x 100
SLA defined for detecting (reporting) and alert and for performing RCA ? ISO 27001 / CoBIT
5.0 / ITIL V3
5.02

Defined KPIs for performance measurement of the SIEM ? ISO 27001 / CoBIT
5.03 5.0 / ITIL V3
Performance/ Risk/ Escalation and other reporting provided for monitoring ISO 27001 / CoBIT
5.04 5.0 / ITIL V3
Outsourcing contract include arrangements for reporting, notification and ISO 27001 / CoBIT
5.05 investigation of security incidents and security breaches? 5.0 / ITIL V3

Availability of services is to be maintained in the event of a disaster? ISO 27001 / CoBIT


5.06 5.0 / ITIL V3
Incident management handling leading to containment, eradication, ISO 27001 / CoBIT
5.07 investigation and closure 5.0 / ITIL V3
2.24 2.76

Maturity Observation Before IS-IM Program Maturity


0 to 5 0 to 5
Perimeter security devices are covered as a
part of monitoring via SIEM. Applications and
Database are not covered. Device coverage is
2 limited to perimeter security devices, DNS and 3
technology controls like web gateway and
content filter/ironport

3 Coverage is 24*7 for monitoring 3

Most of the alerts are default and few alerts


2 are configured but not aligned to risk or threat 3
analysis

22 rules and coverage is not including all


2 3
critical systems of IT and ICS

Device coverage is limited to perimeter


2 security devices, DNS and technology controls 3
like web gateway and content filter/ironport

Reporting is produced and stakeholder also


3 3
posses access to view real time dashboard

Yes, ticketing system is used for logging


2 2
incidents

Information security incidents are identified


and escalated to Aujas by Injazat and existing
2 3
set of ISO/CISO handle incident with SMEs for
network/ application/ system/DB

Not all administrator activities are logged/ all


2 3
critical administrator activities not identified

3 All required information is captured by SIEM 3

Yes, based on alerts priorities timeframes are


2 3
defined

2 Yes, based on alerts, Priorities are defined 2


Yes, the current solution is integrated with
2 Service Desk tool but detailed workflow for 2
escalation is not provided in service contract

Ticketing system can take data from various


2 2
means like API/ email

Defined for perimeter devices and few


2 technical sources, not all critical sources are 3
covered

Yes, but not for information security incident


2 3
(RCA)

Yes, Management reporting consist of key


3 3
metrics

3 Yes, Dashboard contain the parameters 3

2 No 3

2 Yes, covered by service contract 2

Security Handling is left to Aujas and is


2 3
governed by existing process
Response post IS-IM Program

Proposed is inclusion of Application,


Database, technical controls (ICS - AD/
Anti malware, DNS, Firewall, IPS, Routers
and core switches) (IT - nexthink etc)

No change proposed, however with


increase in monitoring of assets and
additional of rules, manpower increment
might be required
Over 200 alerts have been proposed for
monitoring with addition of over 30 rules
identified

Number of rules to go up considering the


latest threat profile

Proposed is inclusion of Application,


Database, technical controls (ICS - AD/
Anti malware, DNS, Firewall, IPS, Routers
and core switches) (IT - nexthink etc)

Report will contain additional items/alerts

Service desk to be used for logging


incidents and reporting/ escalation

Further training and enablement will


mobilize resources based on incident
categorization and complexity

Proposed is critical set of activities with


threshold values that must be identified
and alerted
All required information is captured by
SIEM

Yes, based on alerts, Priorities are


defined
Yes, the current solution is integrated with
Service Desk tool

Ticketing system can take data from


various means like API/ email

Proposed is al critical sources (14) and


additional alert and event monitoring

Proposed is detailed process follow-up


consisting of containment, eradication,
investigation and recovery of
incident/systems

Additional metrics proposed

Yes, Dashboard contain the parameters

Proposed is to handle internally with SME


and ISIRT and other governance bodies

Yes, covered by service contract

Process is fine tuned and detailed


DOMAIN RATING 2.70
Aujas Networks - Information Security Incident Management's Maturity
Assessment
Information Gathering - Process - Information Security Incident Management's
S. No. Tool Maturity
The Information Security Incident Management -
Source 0 to 5
Malicious Code Protection

Does the organization's incident response procedures


1.01 ISO 27001 3
address handling of malware infections?

Is logging enabled to record detection and removal of


1.02 ISO 27001 3
malware events on all systems?
Malware policy
Malware policy and process exist to install, update,
review, scan and enforce policy
2.01 NIST SP-800-83 Rev 1 3

Is malware protection (antivirus, antispam etc.) installed


2.02 on all servers and workstations in the organization ISO 27001 & 27002 2
network?
Does the organization use an automated process to
2.03 ISO 27001 & 27002 3
update its malware solution(s) on a regular basis?

Are incoming email attachments scanned to check for ISO 27001 & 27002,
2.04 3
malware before opening? NIST SP-800-83 Rev 1

Are all removable, replacement and media from external ISO 27001 & 27002,
2.05 3
entities scanned to check for malware before use? NIST SP-800-83 Rev 1

Is sending or receipt of certain types of files (e.g., .exe ISO 27001 & 27002,
2.06 3
files) via email prohibited? NIST SP-800-83 Rev 1

Are prevention software types (e.g., antivirus, content


filtering ) specified for each types of host (e.g., email
2.07 NIST SP-800-83 Rev 1 2
server, web server, laptop, smart phone) and
applications (e.g., email client, web browser).
Host hardening measures

Are unneeded services (particularly network services) ISO 27001 & 27002,
3.01 2
identified and disabled/ removed? NIST SP-800-83 Rev 1

Are default usernames and passwords for OSs and ISO 27001 & 27002,
3.02 2
applications removed/ changed or monitored in SIEM NIST SP-800-83 Rev 1

Is automatic execution of binaries and scripts, including ISO 27001 & 27002,
3.03 3
Auto Run on Windows hosts disabled? NIST SP-800-83 Rev 1

Are the default file associations for file types that are
most frequently used by malware but not by users
3.04 NIST SP-800-83 Rev 1 3
(e.g., .pif, .vbs) changed so that such files are not run
automatically if users attempt to open them.
Anti-Malware
Do you have anti-malware prevention software
ISO 27001 & 27002,
4.01 implemented on your email servers and email 3
NIST SP-800-83 Rev 1
gateways?
Do you have anti-virus/content monitoring software
4.02 implemented on your Internet gateways to screen NIST SP-800-83 Rev 1 3
incoming Internet traffic?
Do you have anti-virus software implemented on the
4.03 mobile computing devices (e.g., PDA, Handheld NIST SP-800-83 Rev 1 1
Personal Computers, Blackberry, or Smart phones)?
Do you have an centralized anti-virus management
ISO 27001 & 27002,
4.04 solution and an automated process for updating virus 3
NIST SP-800-83 Rev 1
definition files?
Do you have a monthly report to summarize the anti-
virus operations (e.g., # of virus circumvented, # of virus
4.05 NIST SP-800-83 Rev 1 3
outbreak, percentage of workstations with latest AV
software, etc.)
Is the Anti Virus is configured for -
4.06 Scanning critical host components such as start-up files NIST SP-800-83 Rev 1 2.5
and boot records.

Perform real-time scans of each file as it is downloaded,


4.07 NIST SP-800-83 Rev 1 3
opened, or executed (on-access scanning).

Supports monitoring the behaviour of common


4.08 applications, such as email clients, web browsers, NIST SP-800-83 Rev 1 3
instant messaging etc.

Are users able to disable or delete antivirus software ISO 27001 & 27002,
4.09 3
from their hosts or are they able to alter critical settings. NIST SP-800-83 Rev 1
2.93

Observation Before IS-IM


Maturity Response post IS-IM Program
Program
0 to 5

Yes, Anti Malware of SEP and Yes, Anti Malware of SEP and McAfee
McAfee EPO is implemented for 3 EPO is implemented for IT and ICS
IT and ICS respectively respectively

Yes and monitored via SIEM 3 Yes and monitored via SIEM

Yes, Anti-Malware policy exist, is


Yes, Anti-Malware policy exist, is enforced
enforced and metrics reported 3
and metrics reported periodically
periodically

Coverage is exhaustive and Coverage is exhaustive and covers all


2
covers all critical devices critical devices

Yes, and is centralized 3 Yes, and is centralized

Attachments are scanned 3 Attachments are scanned

Yes, on demand scan is enabled Yes, on demand scan is enabled for


3
for removable devices removable devices

Yes, executables, binaries are


Yes, executables, binaries are matched
matched and alerted for 3
and alerted for exceptions
exceptions

Additional events and alerts are provided


Yes, coverage is provided 3 for monitoring and prevention in line with
advanced threats and its SIEM rules

Hardening is followed in some Hardening should be followed for all


3
cases and is ad hoc critical devices

Not all devices have default


Proposed is to monitor all default
credentials covered and 3
credentials
monitored

Yes 3 Yes

Yes 3 Yes
Improvements of events to be monitored
Yes, Ironport is implemented 3.5
is proposed

McAfee Web gateway is Improvements of events to be monitored


3.5
implemented is proposed

AV/AM software is not


AV/AM software is not implemented for
implemented for smartphones/ 1
smartphones/ Handheld devices
Handheld devices
Yes, SEP and McAfee ePO is
Yes, SEP and McAfee ePO is
3.5 implemented and further improvement is
implemented
suggested

Yes, Monthly dashboard contain Yes, Monthly dashboard contain


3
information required information required

Yes 3 MBR scanning is added to be monitored

Yes, on demand scan is enabled Yes, on demand scan is enabled for


for removable devices and all 3 removable devices and all type of files
type of files from various sources from various sources

Yes, script execution in browser


Yes, script execution in browser and other
and other communication clients 3
communication clients is enabled for scan
is enabled for scan

Nonusers cannot disable No,users cannot disable technical control


3
technical control implemented implemented
DOMAIN RATING
Aujas Networks - Information Security Incident Management's Maturity Assessment
Information Gathering - Process - Information Security Incident Management's

S. No. Tool

The Information Security Incident Management's Process


1 Perimeter defence

Ability to monitor for intrusion on all ingress and zones hosting critical services for
1.01 Aujas

Type of IPS (Network-based, host based) is used to stop/ prevent unknown


1.02
threats of intrusion?

Does management include dynamic reconfiguration of the IDS/IPS as part of the


1.03
incident response capability.

What is the default action set for the firewalls? (allow/ Deny) and is logging
1.04
enabled for all activities

Are firewall logs monitored in real time or is any firewall log analysis is done and
1.05
at what frequency?
2 Content Filtering/ SPAM filtering

Does the organization use spam filtering software to reduce the amount of
2.01
unsolicited e-mails?

Does the organization utilize web filtering to prevent employees from visiting
2.02
risky/blacklisted/suspicious websites?

2.03 Do both email and web content filtering have use real-time blacklists?

Are application white listing technologies, also known as application control


2.04
programs used to specify which applications are authorized for use on a host?

3 Defensive Architecture
Are applications run a controlled environment that restricts what operations the
3.01 applications can perform and that isolates them from other applications running
on the same host.
Are relatively secured web browsers identified and browser options limited for
3.02
user?
Is Virtualization used to segregate applications and operating systems from each
3.03
other?
4 Wireless
Does the organization employ legacy wireless protocols such as WEP, TKIP, or
4.01 WPA?

Does the organization employ a WLAN intrusion detection system?


4.02

Is logging activated with log entries frequently reviewed by staff?


4.03

To support authentication and data encryption for administrative sessions?


4.04

Do access points log security relevant events and forward them to a remote audit
server in real time?
4.05
2.97 3.12
ssessment

Observation Before IS-IM


Maturity Maturity
Program
Source

All zones are covered for


NIST SP-800-83 Rev 1 3 monitoring in IT and ICS 3.5
environment

HIPS installed on critical


NIST SP-800-83 Rev 1 3 3
systems

Not configured but monitored


NIST SP-800-83 Rev 1 3 on a contineous basis and 3.5
can be done manually

Dafault deny rule exist but


NIST SP-800-83 Rev 1 2.5 logging is not enabled for all 3.5
rules
Monitored in real time via
NIST SP-800-83 Rev 1 3 3.5
SIEM alert

Ironport exist to block spams,


NIST SP-800-83 Rev 1 3 3
malicious content in emails

Yes, Web gateway and


Botnet filter exist in firewall to
protect against the attacks
NIST SP-800-83 Rev 1 3 3
against malicious
website/domains and
blacklisted/greylisted
They are updated and can be
manually updated via
NIST SP-800-83 Rev 1 3 3
additional subscription and
configuration

Application white listing is


NIST SP-800-83 Rev 1 3 3
applied for ICS environment

Yes, it is configured via


NIST SP-800-83 Rev 1 3 various security technical 3
controls

NIST SP-800-83 Rev 1 3 Only IE is alowed 3

NIST SP-800-83 Rev 1 3 Yes 3


ISO 27001 & 27002, WPA and WPA 2 and SSID
3 3
NIST SP-800-83 Rev 1

ISO 27001 & 27002, Wireless to core switch - to


3 3
NIST SP-800-83 Rev 1 firewall and IPS

Wireless controlling system -


ISO 27001 & 27002,
3 separate moniroring system 3
NIST SP-800-83 Rev 1
Logs are monitored

.1 X authentication on the
ISO 27001 & 27002, users/ accessc control
3 3
NIST SP-800-83 Rev 1 system/ Authentication from
AD
Yes, Wireless controlling
ISO 27001 & 27002, system - separate moniroring
3 3
NIST SP-800-83 Rev 1 system
Logs are monitored
Response post IS-IM Program

All zones are covered for monitoring in IT and


ICS environment / Some changes suggested
for improvement detailed in assessment report

HIPS installed on critical systems

Proposed is to add additional IoC in IPS and


update signature/ custom signautres /against
latest threats

Detailed assessment report provides logging


enablement and monitoring

Monitored in real time, additional events


provided for monitoring and alerting

Ironport exist to block spams, malicious content


in emails

Yes, Web gateway and Botnet filter exist in


firewall to protect against the attacks against
malicious website/domains and
blacklisted/greylisted

They are updated and can be manually


updated via additional subscription and
configuration

Application white listing is applied for ICS


environment

Yes, it is configured via various security


technical controls

Only IE is alowed

Yes
WPA and WPA 2 and SSID

Wireless to core switch - to firewall and IPS

Wireless controlling system - separate


moniroring system
Logs are monitored

.1 X authentication on the users/ accessc


control system/ Authentication from AD

Yes, Wireless controlling system - separate


moniroring system
Logs are monitored
DOMAIN RATING 2.13
Aujas Networks - Information Security Incident Management's Maturity Assessment
Information Gathering - Process - Information Security Incident Management's
S.No. Tool Maturity
The Information Security Incident Management People Readiness Source

1.01 Appropriately staffed to handle entire lifecycle of incidents ISO 27001 2

1.02 Is requirements to fulfill incident management role defined NIST 80-083 2

1.03 Are roles and responsibilities documents ISO 27001 2


1.04 Are all members for ISIRT, ISO, CISO identified ISO 27001 3

1.05 Is awareness conducted for all stakeholders ISO 27001 3

1.06 Is appropriate traning provided to all stakeholders / ISIRT / SME ISO 27001 3

1.07 Drill conducted to verify preparedness and application of knowledge ISO 27001 1

Mechanism to identify training and competency requirements and


1.08 ISO 27001 1
measurement for individual members
3.00

Observation Before IS-IM Program Maturity Response post IS-IM Program

Though there is no separate standard for staff Though there is no separate standard for staff
sufficiency, as per RSA best practices, we sufficiency, as per RSA best practices, we propose
3
propose additional ICS security expert to additional ICS security expert to handle information
handle information security incidents security incidents

Detailed qualification, experience and Detailed Description of the role with competency
3
relevant with training is not defined proposed
High level R&R were defined 3 Detailed R&R for all stakeholders
All members are identified 3 All members are identified
There was no awaeness for users to identify Proposed is awareness for all stakeholders via ISIRT
3.5
and report incidents conducted workshop
No training provided to ISIRT and SME
relevant to incident response, however
3.5 Training identified and planned
individual trainings and some relevant
technical training provided
No drill has been conducted so far for
3 Planned drill in Mid-February
measuring incident preparedness

Individual roles have competency but formal


ISIRT training planned in Mid-February, Further
documentation and plan for improvements via 2
specialized training should be planned and executed
formal program does not exist

You might also like