Why did you get your CCSP?

I got my CCSP because of the pervasive shift to the cloud across every technology-driven industry. After gaining experience with
organizations that operate "air-gapped" critical systems, as well as those that run the largest public cloud infrastructures, I came
to understand the pivotal role cloud security would play in bringing the benefits of the cloud to the most mission-critical
systems relied upon by the global community.

Cybersecurity is the collection of tools, policies, security concepts, security safeguards, guidelines, risk
management approaches, actions, training, best practices, assurance and technologies that can be
used to protect the cyber environment and organization and users assets.

The information systems audit of application software should mainly cover the following areas:-
Adherence to business rules in the flow and accuracy in processing
Validations of various data inputs
Logical access control and authorization
Exception handling and logging
The steps to be performed in carrying out an application software review are as follows:-
Evaluate the environment under which the application runs.
Correct any weaknesses found at the end of an applications review/development in the software that could lead to
errors or compromises in security.
Verify how errors and exceptions are handled. In many activities software provides options and ways to reverse
transactions, correct errors, allow transactions under special circumstances, etc.
Verify access control in application software.
Validate every input to the system against the applicable criteria.
Run through the various menus, features and options to identify processes and options for conformance to business
rules and practices.
Study key functions of the software at work by observing and interacting with operating personnel during work.
Study and review of documentation relating to the application.
1. Internal control: - is a process for assuring achievement of an organization's objectives in operational effectiveness
()
and efficiency( ), reliable financial reporting, and compliance with laws, regulations and policies.

COSO defines internal control as having five components:-

1. Control Environment-sets the tone for the organization, influencing the control consciousness of its people. It is the
foundation for all other components of internal control.
2. Risk Assessment-the identification and analysis of relevant risks to the achievement of objectives, forming a basis for how
the risks should be managed

3. Information and Communication-systems or processes that support the identification, capture, and exchange of
information in a form and time frame that enable people to carry out their responsibilities

4. Control Activities-the policies and procedures that help ensure management directives are carried out.

5. Monitoring-processes used to assess the quality of internal control performance over time.

Control activities may also be explained by the type or nature of activity. These include (but are not limited to):
Segregation of duties separating authorization, custody, and record keeping roles to prevent fraud or error by one person.
Authorization of transactions review of particular transactions by an appropriate person.
Retention of records maintaining documentation to substantiate transactions.
Supervision or monitoring of operations observation or review of ongoing operational activity.
 Physical safeguards usage of cameras, locks, physical barriers, etc. to protect property, such as merchandise inventory.
Top-level reviews analysis of actual results versus organizational goals or plans, periodic and regular operational reviews,
metrics, and other key performance indicators(KPIs).
IT general controls Controls related to: a) Security, to ensure access to systems and data is restricted to authorized
personnel, such as usage of passwords and review of access logs; and b) Change management, to ensure program code is
properly controlled, such as separation of production and test environments, system and user testing of changes prior to
acceptance, and controls over migration of code into production.
Information Systems Operations
Batch job, report and online transaction processing procedures
Controls and testing procedures to determine if organizations operations around scheduling, performance, and monitoring
of IT programs and processes are adequately supervised:
Processing to successful and timely completion
Authorization and integrity of job and transaction processing
Automated scheduling tools (management, security, access to such tools, etc.)

Backup and recovery

Controls to ensure organizations financial data is appropriately managed during storage:
Data retention tools (management, security, access to such tools, etc.)
Backups and retention of data (planning, scheduling, and supervision)
Backup tapes (management, storage, archival, readability assessments, encryption and more).

Physical security
Controls and test steps to determine if facilities that house relevant information-processing and storage
infrastructure are appropriately managed:
Physical access mechanisms
Authority to administer physical access mechanisms
Physical access control procedures (approvals from management, access disablement, monitoring and access
recertification procedures)

Information Security
Configurable security parameters and settings
Controls and testing procedures to assess the effectiveness of the system configuration and security settings:
Password requirements
Procedures to safeguard default vendor accounts
Patching procedures to prevent exploitation of known security vulnerabilities
Procedures to detect security events and respond to security incidents
Procedures to detect unauthorized changes to the security and configuration settings
Configuration baselines
Privileged system administration access

Logical access controls

A set of controls and testing guidance to determine if access to the computer systems is restricted to authorized
individuals:
Privileged user administration access
Logical access control procedures (access authorization, access disablement, monitoring and access recertification
procedures)
Segregation of duties
Information security techniques to prevent the disclosure of sensitive and confidential information (encryption of
data in transit, masking or scrambling of data in cloned environments, etc.)

Change Management
Development procedures
 Controls and audit guidelines to determine if changes to the key financial applications, databases, network and
systems software are appropriately developed:
A formal change management procedure addressing entity's change management requirements
Assessment of method(s) for logging changes to the production environment
Controls to ensure that testing is performed in accordance with the test strategy prepared and approved by system
owners and development management
Controls to ensure that end user acceptance testing is performed in accordance with the test strategy prepared and
approved by business owners
Segregation of production environment from development and test environments
Implementation procedures
Audit guidelines to determine if changes to the key financial applications, databases, network and systems software
are appropriately implemented:
Business risk assessment and business impact analysis
Authorization by management
Source code control/version control system to maintain copies of the prior versions of the production source code
Rollback strategy
Restriction of access to the production environment
Post-implementation assessment

IT application controls Controls over information processing enforced by IT applications, such as edit checks to validate
data entry, accounting for transactions in numerical sequences, and comparing file totals with control accounts.
Divide in 3 segments 1. Data 2.Function 3.Processes
Identify all subsystems
o Identify all subsystems associated with this application. Middleware and security
o Middleware is the software that connects software components or enterprise applications. Middleware is the
software layer that lies between the operating system and the applications on each side of a distributed computer
network
System Interfaces
o Detail what happens when other applications interface (manually or electronically) with this application.
o Document what is received from and what is sent to these other applications.
o Determine how end-users verify or establish assurances that interfaces are providing complete, accurate and
authorized data.
End-Users
o Evaluate whether user access coincides with assigned responsibility.
o Determine from end-user management what they perceive to be the risks, exposures and limitations
associated with the system.
o Evaluate this training to determine if it is adequate, current and available for new people.
File Handling
o Determine the retention periods for the various key application data files.
- Evaluate if the retention periods satisfy management reporting, IRS reporting, other legal and internal
accounting requirements.
Backup and Recovery:- RPO/RTO
o Identify the key system files and evaluate whether the files are appropriate.
- Determine how often key files are backed up.
- Determine if copies of these backup files are stored at a suitable off-site facility
o Determine if application recovery plans exist (both technical and end-user) for restoring from short-term and
long-term interruption of computer processing.
- Determine if these application recovery plans have been tested
Data Origin
o To determine that controls over the preparation, collection, and processing of source documents ensure the
accuracy, completeness, and timeliness of data before they reach the application.
 Data Input
o To determine that manual and automated controls over data entry (batch or online), data validation, error
identification and reporting, and error correction and reentry are effective to ensure that data are completely and
accurately entered into the application.
Processing
o To determine that controls over application programs and related computer operations ensure the accuracy,
completeness, and timeliness of data during batch or real time processing.
Data Output
o To determine that controls over balancing and reconciliation, distribution of output, handling of negotiable
documents, and output retention are effective to ensure that output is accurate and distributed to authorized
personnel on a timely basis.
Logging/Monitoring/Incident Handling
o Review change control change control as a set of six steps
1. Record / Classify, 2. Assess, 3. Plan, 4. Build / Test, 5. Implement, 6. Close / Gain Acceptance
Application Development

ID Control Public Private Restricted

AS-1 Application development includes reviews for security vulnerabilities Recommended Recommended Required
throughout the development lifecycle

AS-2 Application change control procedures are documented and followed Recommended Recommended Required

AS-3 Controls are in place to protect the integrity of application code Recommended Recommended Required

AS-4 Application validates and restricts input, allowing only those data types Required Required Required
that are known to be correct *

AS-5 Application executes proper error handling so that error messages do Required Required Required
not reveal potentially harmful information to unauthorized users (e.g.
detailed system information, database structures, etc.)

AS-6 Default and/or vendor supplied credentials are changed or disabled prior Required Required Required
to implementation in a staging or production environment

AS-7 Functionality that allows the bypass of security controls is removed or Required Required Required
disabled prior to implementation in a staging or production environment

Session Management
ID Control Public Private Restricted

AS-8 Application sessions are uniquely associated with Recommended for READ access; Required Required Required
an individual or system for all other access

AS-9 Session identifiers are generated in a manner that Required Required Required
makes them difficult to guess

AS-10 Session identifiers are regenerated a change in the Required Required Required
access profile of a user or system *
AS-11 Active sessions timeout after a period of inactivity Recommended Required Required

Vulnerability Management
ID Control Public Private Restricted

AS- Applications are periodically tested for security vulnerabilities (e.g. Recommended Recommended Required
12 vulnerability scanning, penetration testing, etc.)

AS- Application security patches are deployed in a timely manner Required Required Required
13

Application Logging
ID Control Public Private Restricted

AS- Successful attempts to access an Required for privileged access; Required for privileged access; Required
14 application are logged Recommended for all other Recommended for all other
access access

AS- Failed attempts to access an Required for privileged access; Required for privileged access; Required
15 application are logged Recommended for all other Recommended for all other
access access

AS- Attempts to execute an administrative Recommended Recommended Recommended

16 command are logged *

AS- Changes in access to an application Required Required Required

17 are logged (e.g. adding, modifying or
revoking access)

AS- Application logs are reviewed on a Recommended Recommended Required

18 periodic basis for security events

AS- Application logs are protected against Required Required Required

19 tampering

Supplemental Guidance
AS-05: Input validation plays an important part in application security. For example, if a data entry field is asking for a phone
number, the application should validate that the value entered matches a format similar to (###) ###-####. If a data entry field
is asking for a date, the application should validate that the value entered matches a format similar to MM/DD/YYYY. If an
application does not have controls in place to validate input, a malicious user may be able to enter data that results in
unintended consequences, such as application failure or unauthorized access to potentially sensitive data.
AS-12: Not only should a session identifier (SID) be unique to an individual or system but it should also be unique to an
individual's or system's access profile.
AS-16: PAM/Administrative commands are those commands that typically require some level of privileged access to execute.
General Computer Controls:- ITGCs may also be referred to as General Computer Controls (GCC) which are defined as: Controls,
other than application controls, which relate to the environment within which computer-based application systems are
developed, maintained and operated, and which are therefore applicable to all applications. The objectives of general controls
are to ensure the proper development and implementation of applications, the integrity of program and data files and of
computer operations. Like application controls, general controls may be either manual or programmed. Examples of general
controls include the development and implementation of an IS strategy and an IS security policy, the organization of IS staff to
separate conflicting duties and planning for disaster prevention and recovery.

Internal Control:- An effective internal control system is one that exhibits certain characteristics that facilitate the
evaluation and improvement of existing internal control systems by highlighting areas where the practical application of such
guidelines often fails in many organizations
Type of Control:- There are basically four main types of internal controls that service organizations and their service auditors
should be concerned with, which are namely: manual controls, IT dependent manual controls, application controls, and IT
general controls. Of course there are innumerable variations on the specifics of controls, though these four control types are
the ones service organizations and their auditors should concern themselves.
Manual Controls:- Manual controls are performed by individuals outside of a system. Examples of manual controls could be a
supervisor review and sign-off of a document, or bank reconciliation, or having an employee sign a privacy policy
acknowledgement.
IT Dependent Manual Controls:- Similar to manual controls, these controls require some level of system involvement. For
example, a system generated report that lists users that have not accessed a particular system within the past 90 days. The
control may require an administrator to review such list and disable certain users as a result.
Application controls:- These types of controls may be system configuration settings. For example, if the system is configured to
lock-out a user that enters an incorrect password after three attempts. Another example, could be the system is configured to
automatically download and apply updates to malware detection software.
IT General Controls:- This type of control is usually the focal point of most SOC audits. IT general controls comprise of logical
access, program change, and physical security. For example, user access administration controls are used so that the right
people have the right access to system resources (i.e., right people & right access). These processes and the controls supporting
these processes are IT general controls.
In addition to the types of controls named, internal controls are either preventive or detective in nature.
CAAT
Traditional audit example
The traditional method of auditing allows auditors to build conclusions based upon a limited sample of a population, rather
than an examination of all available or a large sample of data.
Computer-assisted audit techniques (CAATs) make use of computer applications, such as ACL, IDEA, VIRSA, SAS, SQL, Excel,
Crystal Reports, Business Objects, Access, and Word, to automate and facilitate the audit process. The use of CAATs helps to
ensure that appropriate coverage is in place for an application control review, particularly when there are thousands, or
perhaps millions, of transactions occurring during a test period. In these situations, it would be impossible to obtain adequate
information in a format that can be reviewed without the use of an automated tool.
CAATTs alternative
CAATTs, not CAATs, addresses these problems. CAATTs, as it is commonly used, is the practice of analyzing large volumes of data
looking for anomalies. A well designed CAATTs audit will not be a sample, but rather a complete review of all transactions.
Using CAATTs the auditor will extract every transaction the business unit performed during the period reviewed. The auditor
will then test that data to determine if there are any problems in the data.
Traditional audit vs CAATTs on specific risks
Another advantage of CAATs is that it allows auditors to test for specific risks. For example, an insurance company may want to
ensure that it doesn't pay any claims after a policy is terminated. Using traditional audit techniques this risk would be very
difficult to test. The auditor would "randomly select" a "statistically valid" sample of claims (usually e if any of those claims were
processed after a policy was terminated. Since the insurance company might process millions of claims the odds that any of
those 3050 "randomly selected" claims occurred after the policy was terminated is extremely unlikely.
Using CAATTs the auditor can select every claim that had a date of service after the policy termination date. The auditor then
can determine if any claims were inappropriately paid. If they were, the auditor can then figure out why the controls to prevent
this failed. In a real life audit, the CAATTs auditor noted that a number of claims had been paid after policies were terminated.
Testing Design Effectiveness:-
The control design is closely related to control objectives. There is a need to assess the design effectiveness. The control should
be properly constructed to achieve the related control objectives. You need to document the owner of the control, description
of process flow, is the control properly designed? i.e. if the control is used as directed, will it accomplish its objective?. if the
control is deemed deficient, what are its specific shortcomings?
1. The TOD forms the baseline of testing for each control the test of design (TOD) will be on work paper for each process or
some people prefer to make a work paper for each control. The auditors are looking for you to create these documents for
them so that they can review the design of the control. Some companies use narratives instead of tests of design. These serve a
few purposes for the auditors. one is that they can familiarize themselves with the controls and how the process works. Also if
walkthrough evidence is kept it serves as an example of the test of effectiveness (TOE). Second if a control is not designed
properly then it cannot be tested and so the TOD is important in saving time and money on the TOE side. The auditors usually
will perform their own test of design, but if yours is done well and documented they may agree to rely on yours and you can
save on audit fees.
1. The TOD forms the baseline of testing for each control. By building the TOD first, which is quick and straightforward, you can
establish the foundation for all your Tests of Effectiveness or TOEs.
2. In executing the TODs, you can quickly determine if there have been any changes in the system that require changes to the
TOD or further documentation. Specifically, if you run the TOD and get a failure, you know that either something has changed in
your system, which means the control needs to be reviewed or modified, or you used bad data, which means that the business
needs to get involved and evaluate why this occurred.

1. The auditor should test the design effectiveness of controls by determining whether the company's controls, if they are
operated as prescribed by persons possessing the necessary authority and competence to perform the control effectively,
satisfy the company's control objectives and can effectively prevent or detect errors or fraud that could result in material
misstatements in the financial statements.
2. Procedures the auditor performs to test design effectiveness include a mix of inquiry of appropriate personnel,
observation of the company's operations, and inspection of relevant documentation. Walkthroughs that include these
procedures ordinarily are sufficient to evaluate design effectiveness.
Testing Operating Effectiveness
3. The auditor should test the operating effectiveness of a control by determining whether the control is operating as
designed .
III Line of defense:-
The First Line of Defense: Operational Management: - Operational management is responsible for maintaining effective
internal controls and for executing risk and control procedures on a day-to-day basis. Operational management identifies,
assesses, controls, and mitigates risks, guiding the development and implementation of internal policies and procedures and
ensuring that activities are consistent with goals and objectives
The Second Line of Defense: Risk Management and Compliance Functions:-
A risk management function (and/or committee) that facilitates and monitors the implementation of effective risk
management practices by operational management and assists risk owners in defining the target risk exposure and reporting
adequate risk-related information throughout the organization.
A compliance function to monitor various specific risks such as noncompliance with applicable laws and regulations. In this
capacity, the separate function reports directly to senior management, and in some business sectors, directly to the governing
body. Multiple compliance functions often exist in a single organization, with responsibility for specific types of compliance
monitoring, such as health and safety, supply chain, environmental, or quality monitoring.
The Third Line of Defense: Internal Audit:-
A broad range of objectives, including efficiency and effectiveness of operations; safeguarding of assets; reliability and
integrity of reporting processes; and compliance with laws, regulations, policies, procedures, and contracts.
All elements of the risk management and internal control framework, which includes: internal control environment; all
elements of an organizations risk management framework (i.e., risk identification, risk assessment, and response); information
and communication; and monitoring.

Section Title Description

Corporate Responsibility Certifies that financial statement accuracy and operational activities have been
302 for Financial Reports documented and provided to the CEO and CFO for certification

404 Management Operational processes are documented and practiced demonstrating the origins of
 data within the balance sheet. SOX Section 404 (Sarbanes-Oxley Act Section 404)
Assessment of Internal mandates that all publicly traded companies must establish internal controls and
Controls procedures for financial reporting and must document, test and maintain those
controls and procedures to ensure their effectiveness.

Real-time Issuer Public companies must disclose changes in their financial condition or operations in
409 Disclosures real time to protect investors from delayed reporting of material events

Requires public companies and their public accounting firms to retain records,
including electronic records that impact the companys assets or performance.
Criminal Penalties for
802 Fines and imprisonment for those who knowingly and willfully violate this section
Altering Documents
with respect to (1) destruction, alteration, or falsification of records in federal
investigations and bankruptcy and (2) destruction of corporate audit records.

SOC 1: Internal Controls over Financial Reporting (ICFR).

SOC 2: Controls at a service organization that are relevant to security, availability, processing integrity confidentiality, or
privacy.
SOC 1 Type 1 & 2 report:- In its simplest form, SOC 1 is a report on controls at a service organization relevant to a user entity's
internal control over financial reporting. A type 1 (design of controls, as of a single point-in-time) report focuses on a
description of a service organizations system and on the suitability of the design of its controls to achieve the related control
objectives included in the description, as of a specified date. A type 2 report contains the same opinions as a type 1 report with
the addition of an opinion on the operating effectiveness of the controls to achieve the related control objectives included in
the description throughout a specified period. A tye 2 (operating effectiveness over the entire reporting period) reports also
includes a detailed description of the service auditors tests of controls and results. Use of the report is restricted to the
management of the service organization, user entities, and user auditors.
SOC 2:- Report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or
privacy. Uses the trust services criteria TSP.
SOC 3:- This is a trust services report for service organizations. Covers the same subject matter as SOC 2.
Does not include a description of the service auditors tests of controls and results. Also, the description of the system is less
detailed than the description in a SOC 2 report. A seal can be issued on a service organizations website
 RISK Management:-

Risk management constituent processes

ISO/IEC 27005:2008 BS 7799-3:2006 SP 800-30 Risk IT
Context establishment: - The purpose is usually Organizational RG and RE Domains more precisely
the compliance with legal requirements and context RG1.2 Propose IT risk tolerance,
provide evidence of due diligence supporting
RG2.1 Establish and maintain accountability for
an ISMS that can be certified. The scope can be
IT risk management
an incident reporting plan, a business
RG2.3 Adapt IT risk practices to enterprise risk
continuity plan. Another area of application
practices,
can be the certification of a product.
RG2.4 Provide adequate resources for IT risk
management,
RE2.1 Define IT risk analysis scope.
Risk assessment:- A study of the Risk assessment Risk RE2 process includes:
vulnerabilities, threats, likelihood, loss or assessment RE2.1 Define IT risk analysis scope.
impact, and theoretical effectiveness of
security measures. Than it will use the results RE2.2 Estimate IT risk.
of a risk assessment to develop security RE2.3 Identify risk response options.
requirements and specifications. The process RE2.4 Perform a peer review of IT risk
of evaluating threats and vulnerabilities, analysis.
known and postulated, to determine expected RE 2.3 Identify risk response options
loss and establish the degree of acceptability RR2.3 Respond to discovered risk exposure and
to system operations. opportunity
 Risk
assesment, further divided in:
1. Risk identification
Risk treatment 1. Risk treatment Risk
Identification of Options, 2. and mitigation
Development of action plan 3. Approval management
of action plan, 4. Implementation of decision making
action plan, 5.
identification of residual Risks
Risk acceptance RG3.4 Accept IT risk
Risk communication Ongoing risk RG1.5 Promote IT risk-aware culture
management RG1.6 Encourage effective communication of IT
activities risk
RE3.6 Develop IT risk indicators.
Risk monitoring and review Evaluation RG2 Integrate with ERM.
and RE2.4 Perform a peer review of IT risk analysis.
assessment
RG2.5 Provide independent assurance over IT
risk management

ISO 27005 Risk IT

RE2 Analyse risk comprises more than what is described by the ISO 27005 process step. RE2 has as its
objective developing useful information to support risk decisions that take into account the business
relevance of risk factors.
Risk analysis

RE1 Collect data serves as input to the analysis of risk (e.g., identifying risk factors, collecting data on
the external environment).

Risk Risk identification states what could cause a potential loss; the following are to be identified
identification
assets, (i.e. hardware, software, personnel, site, organization structure)

threats

vulnerabilities

Consequences

related business processes

 Risk scenarios/ Risk factors

There are two methods of risk assessment in information security field, quantitative and qualitative.
quantitative risk assessment is a mathematical calculation based on security metrics on the asset (system
or application). For each risk scenario, taking into consideration the different risk factors a Single loss
expectancy (SLE) is determined. Then, considering the probability of occurrence on a given period basis,
for example the annual rate of occurrence (ARO), the Annualized Loss Expectancy is determined as the
product of ARO X SLE.[6] It is important to point out that the values of assets to be considered are those of
all involved assets, not only the value of the directly affected resource.
(SLE) is the monetary value expected from the occurrence of a risk on an asset
Single-loss expectancy (SLE) = Asset value (AV) X Exposure factor (EF)
Risk estimation
Qualitative risk assessment (three to five steps evaluation, from Very High to Low) is performed when the
organization requires a risk assessment be performed in a relatively short time or to meet a small budget,
a significant quantity of relevant data is not available, or the persons performing the assessment don't
have the sophisticated mathematical, financial, and risk assessment expertise required.[16] Qualitative risk
assessment can be performed in a shorter period of time and with less data. Qualitative risk assessments
are typically performed through interviews of a sample of personnel from all relevant groups within an
organization charged with the security of the asset being assessed. Qualitative risk assessments are
descriptive versus measurable. Usually a qualitative classification is done followed by a quantitative
evaluation of the highest risks to be compared to the costs of security measures.

RE2.2 Estimate IT risk (Risk Evaluation is the process used to compare the estimated risk against the
Risk evaluation
given risk criteria so as to determine the significance of the risk.)
**Note:- If it is "for something to happen" it is related to the "occurrence." The exposure factor is related to the expected loss.
For example, if forest fires occur about once every five years and present a risk to a building, the ARO is .20 (1/5).
If a forest fire is expected to reduce the value of the building by 20% (say from $1,000,000 to $800,000) the exposure factor is .
20 (800,000 / 1,000,000)
That said, I don't think you'll see the EF mentioned in the Security+ exam. The focus is more on single loss expectancy (SLE),
annualized rate of occurrence (ARO), annualized loss expectancy (ALE).
The SLE is the cost of any single loss.
The ARO indicates how many times you can expect the loss in a year.
The ALE is calculated as SLE x ARO.
The benefit of knowing this is to calculate the value of a control.
In general, if a control is less than the ALE, it is worth the money to invest in it. If a control costs more than the ALE, it is not
worth the cost. If the control is about the same as the ALE, it requires a deeper analysis.

Risk appetiteThe broad-based amount of risk a company or other entity is willing to accept in pursuit of its mission (or vision)
Risk toleranceThe acceptable variation relative to the achievement of an objective (and often is best measured in the same
units as those, used to measure the related objective)
ISO 27K1 Outline :- 27k1 1007 133 controls 11 Domain in 2013 its 14 domains 114/97 controls

A.5 Information security policies controls on how the policies are written and reviewed
A.6 Organization of information security controls on how the responsibilities are assigned; also includes the controls for
mobile devices and teleworking
 A.7 Human resources security controls prior to employment, during, and after the employment
A.8 Asset management controls related to inventory of assets and acceptable use, also for information classification and
media handling
A.9 Access control controls for Access control policy, user access management, system and application access control, and
user responsibilities
A.10 Cryptography controls related to encryption and key management
A.11 Physical and environmental security controls defining secure areas, entry controls, protection against threats,
equipment security, secure disposal, clear desk and clear screen policy, etc.
A.12 Operational security lots of controls related to management of IT production: change management, capacity
management, malware, backup, logging, monitoring, installation, vulnerabilities, etc.
A.13 Communications security controls related to network security, segregation, network services, transfer of
information, messaging, etc.
A.14 System acquisition, development and maintenance controls defining security requirements and security in
development and support processes
A.15 Supplier relationships controls on what to include in agreements, and how to monitor the suppliers
A.16 Information security incident management controls for reporting events and weaknesses, defining responsibilities,
response procedures, and collection of evidence
A.17 Information security aspects of business continuity management controls requiring the planning of business
continuity, procedures, verification and reviewing, and IT redundancy
A.18 Compliance controls requiring the identification of applicable laws and regulations, intellectual property protection,
personal data protection, and reviews of information security
Major challenge in implementing SOX control was implementing Role Base access control (after 2012 incident and merger
with ABN AMRO Bank) mgmnt decided to have standard RBAC across all the BAU & Platform and I have received resistance
from Team on technical ground , since these systems are there past 15-20 years and we dont know what will happen or
break down system if remove XX group. So I sat with team and business and did coordination reviewing technical
documents on impact gaining understand of system and linked system to close this task.
Second biggest challenge was implementing controls and effectiveness on Archived data

The Federal Financial Institutions Examination Council (FFIEC) is a formal U.S. government interagency body that includes
five banking regulatorsthe Federal Reserve Board of Governors (FRB), the Federal Deposit Insurance Corporation (FDIC),
the National Credit Union Administration (NCUA), the Office of the Comptroller of the Currency (OCC), and the Consumer
Financial Protection Bureau(CFPB). It is "empowered to prescribe uniform principles, standards, and report forms to
promote uniformity in the supervision of financial institutions". It also oversees real estate appraisal in the United
States. Its regulations are contained in title 12 of the Code of Federal Regulations.
Cybersecurity:- Comptroller of the Currency and FFIEC Chair Thomas J. Curry stated on May 8, 2014, that "helping to make
banks less vulnerable and more resilient to cyber-attacks" has been one of his top priorities.

SAP audit plan and testing guidelines to assess batch job and background session processing and administration functions in
SAP R/3:

1. Batch scheduling and batch processing authorizations in SAP R/3

Ability to delete jobs of other users

Ability to administer background sessions in SAP R/3
Ability to schedule jobs under different user IDs
Access to the batch input management functionality in SAP R/3
Monitoring procedures to identify processing errors and/or issues & much more.
 2. Guidance on auditing end-user authorization and administration functions in SAP R/3:

Access to maintain roles, authorizations and authorization profiles

Access to maintain the assignment of the authorization objects to transactions
User master record maintenance in SAP R/3
Access to assign roles or profiles to users
Controls to ensure access to the SAP R/3 system is authorized by management
Controls to ensure access to the SAP R/3 is disabled for employees who no longer require such access, etc.

3. Guidance on auditing safeguards against unauthorized access to or modifications of programs and data:

Access to edit and execute programs online and in the background

Access to modify table content in SAP R/3, including critical systems tables or security tables and client-independent
tables
Access to maintain SAP R/3 Data Dictionary
Security of the custom tables, custom programs, and custom transactions, etc.

4. Guidance on auditing implementation and administration of the system configuration & security settings:

Access to maintain/configure application server parameters

User access to maintain instances
Configuration of the SAP R/3 password parameters
Security of the vendor supplied user IDs
Access restriction to the powerful SAP R/3 profiles
Locking critical and sensitive transaction codes
Security of the remote access to/from the system, including interface communications, etc.

SAP audit guidance on auditing change management and control:

System configuration to enforce appropriate change management process to prevent changes made directly in
production
Ensuring that SAP R/3 system landscape supports separation of production environment from development
environment
Access policies over transports
Security of the developer keys
Controls to ensure that access to develop programs is not allocated in production and more.

Domain Recommended Key Controls

 SAP modification requests for normal and emergency changes,
test results, IT and business owners approvals, and confirmations
for installation in production are documented and retained for at
least two years and available for internal and external audit testing.

SAP modifications are created in the development environment,

tested in a quality assurance environment, and transported by an
SAP administrator into the production environment. The SAP
administrator obtains and files evidence of IT and the business
owners approvals before transporting changes into production.
Change
Management
Developers and business analysts do not have rights to import
changes into the production environment.

The production client is kept locked for direct configuration

changes and is unlocked and locked back via SCC4 when such
changes are required (e.g. for number range updates and
accounting period definitions).

Every quarter, an IT manager reviews the lists of imports and

direct changes in production and confirms changes were
documented and approved. The IT manager performing these
reviews should not have rights to import and make SCC4 changes
in production.

Access to modifications of the SAP security parameters is

restricted to SAP administrators.

SAP security parameters and the administrative accounts for the

SAP application, database, and servers are set as defined in the
company security policies and in the IT narratives.

Access
Management
The SAP administrators grant, change, and revoke employees'
and contractors' SAP access after authorization by their
supervisors, the business owners for the respective modules, and
the SAP team. The SAP administrators also disable SAP access
for employees and contractors who no longer work for the
company as soon as they receive requests to do so.

Business owners review the lists of SAP user accounts with

update rights in their areas at least once a year and confirm the
users need such access to perform their duties.

Operations Scheduled job creation and changes follow change management

procedures.
 Daily, SAP administrators monitor and send e-mails to IT
management and operations teams with status reports and
confirmations that exceptions in the following areas were
addressed:

Scheduled jobs failures.

Interface failures.

Backup failures.

Locked accounts.

Backup and recovery backup policies exist and are documented.

Backup schedules, rotation, and retention periods meet policy
requirements. Backup media are secured onsite and off-site at all
times. Restoration process is periodically tested (e.g., via the
quality assurance environment, refresh production backups
determine if it's possible to recreate the production environment in
case of disaster).

SAP User Master Record

The concept of user master records User master records defines the user accounts for enabling access to the SAP
system. The user master record is mainly used for user administrative and Authorization management (Role
Administration). Normally, the user master record contains the user id as well as a wealth of other information which
can be used by SAP system administrators in managing users effectively.
For example, the user master record contains information which validates a user log on session. User master record
stores important information like users access rights to SAP, user's passwords, the authorization profiles and so
on. User master records can be accessed using the Transaction T Code SU01. In t-code SU01, users can be
displayed by user id or in case one does not know the user id, users can be displayed using all possible entries.
You need authorizations to create or maintain user master records:

Authorization to create and/or maintain user master records and to assign a user group
(Auth.object S_USER_GRP).
Authorization for the authorization profiles you want to assign to users (Auth.objectS_USER_PRO).
Authorization to create and maintain authorizations (object S_USER_AUTH).
Authorization to protect roles. You can use this authorization object to determine which roles may be
processed and which activities (Create, Display, Change and so on) are available for the role(s)
(object S_USER_AGR).
Authorization for transactions that you may assign to the role and for which you can assign authorization at
the start of the transaction in the Profile Generator (objectS_USER_TCD).
Authorization to restrict the values which a system administrator can insert or change in a role in the Profile
generator (S_USER_VAL)

Authorization Checks Starting SAP Transactions:

When a user starts a transaction, the system performs the following checks:

The system checks in table TSTC whether the transaction code is valid and whether the system
administrator has locked the transaction.
The system then checks whether the user has authorization to start the transaction. The SAP system
performs the authorization checks every time a user starts a transaction from the menu or by entering a command.
Indirectly called transactions are not included in this authorization check. For more complex transactions, which call
other transactions, there are additional authorization checks.
The authorization object S_TCODE (transaction start) contains the field TCD(transaction code). The user
must have an authorization with a value for the selected transaction code.
If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also
requires the suitable defined authorization object (TSTA, tableTSTCA).
If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction.
This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you
should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).
The system checks whether the transaction code is assigned an authorization object. If so, a check is made
that the user has authorization for this authorization object.
The check is not performed in the following cases:
You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using
check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot
deactivate the check for objects from the SAP NetWeaver and HR areas.
This can be useful, as a large number of authorization objects are often checked when transactions are
executed, since the transaction calls other work areas in the background. In order for these checks to be executed
successfully, the user in question must have the appropriate authorizations. This results in some users having more
authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore
deactivate authorization checks of this type in a targeted manner using transaction SU24.
You have globally deactivated authorization objects for all transactions with transactionSU24 or
transaction SU25.
So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the
profile parameter AUTH/NO_CHECK_IN_SOME_CASESto Y (using transaction RZ10).
 All of the above checks must be successful so that the user can start the transaction. Otherwise, the
transaction is not called and the system displays an appropriate message.
Checking Assignment of Authorization Groups to Tables
You can also assign authorization groups to tables to avoid users accessing tables using general access
tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have
authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables
with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked
authorization object is S_TABU_DIS.

Profile Parameters for Logon

To make the parameters globally effective in an SAP System (system profile parameters),
set them in the default system profile DEFAULT.PFL. However, to make them instance-
specific, you must set them in the profiles of each application server in your SAP System.

To display the documentation for one of the parameters, choose Tools >> CCMS>>
Configuration >> Profile Maintenance (transaction RZ10), specify the parameter name and
choose Display.

Password Checks:- Enter transaction RZ10 in command field and enter. Here you can
check difference parameters related to Login System

Parameters Explanation

Defines the minimum length of the

login/min_password_lng password.
Default value: 3; permissible values: 3 8

Defines the minimum number of digits (0-

9) in passwords.
login/min_password_digits
Default value: 0; permissible values: 0 8
Available as of SAP Web AS 6.10

Defines the minimum number of letters (A-

Z) in passwords.
login/min_password_letters
Default value: 0; permissible values: 0 8
Available as of SAP Web AS 6.10

login/min_password_specials Defines the minimum number of special

characters in the password Permissible
 special characters are ()!\"@ $%&/
()=?'`*+~#-_.,;:{[]}\\<>
Default value: 0; permissible values: 0 8
Available as of SAP Web AS 6.10

Defines the minimum number of characters

that must be different in the new password
login/min_password_diff compared to the old password.
Default value: 1; permissible values: 1 8
Available as of SAP Web AS 6.10

Defines the validity period of passwords in

days.
login/password_expiration_time
Default value: 0; permissible values: any
numerical value

If the user logs on with Single Sign-On,

checks whether the user must change his
login/password_change_for_SSO or her password.
Available as of SAP Web AS 6.10, as of SAP
Basis 4.6 by Support Package

Controls the deactivation of password-

based logon
login/disable_password_logon
Available as of SAP Web AS 6.10, as of SAP
Basis 4.6 by Support Package

Controls the deactivation of password-

based logon for user groups
login/password_logon_usergroup
Available as of SAP Web AS 6.10, as of SAP
Basis 4.6 by Support Package

Multiple Logon

Parameters Explanation

Controls the deactivation of multiple dialog

login/disable_multi_gui_login logons
Available as of SAP Basis 4.6

List of excepted users (multiple logon)

login/multi_login_users
Available as of SAP Basis 4.6

Incorrect Logon

Parameters Explanation

Defines the number of unsuccessful logon

attempts before the system does not allow
any more logon attempts. The parameter is
login/fails_to_session_end
to be set to a value lower than the value of
parameter login/fails_to_user_lock.
Default value: 3; permissible values: 1 -99

Defines the number of unsuccessful logon

attempts before the system locks the user.
login/fails_to_user_lock
By default, the lock applies until midnight.
Default value: 12; permissible values: 1 -99

login/failed_user_auto_unlock Defines whether user locks due to

unsuccessful logon attempts should be
 automatically removed at midnight.
Default value: 1 (Lock applies only on same
day); permissible values: 0, 1

Initial Password: Limited Validity

Parameters Explanation

Defines the validity period of passwords

for newly created users.
login/password_max_new_valid
Available as of SAP Web AS 6.10, as of
SAP Basis 4.6 by Support Package

Defines the validity period of reset

passwords.
login/password_max_reset_valid
Available as of SAP Web AS 6.10, as of
SAP Basis 4.6 by Support Package

SSO Logon Ticket

Parameters Explanation

Allows or locks the logon using SSO ticket.

login/accept_sso2_ticket Available as of SAP Basis 4.6D, as of SAP
Basis 4.0 by Support Package

Allows the creation of SSO tickets.

login/create_sso2_ticket
Available as of SAP Basis 4.6D

Defines the validity period of an SSO

login/ticket_expiration_time ticket.
Available as of SAP Basis 4.6D

The logon ticket is only transferred using

login/ticket_only_by_https HTTP(S).
Available as of SAP Basis 4.6D

When logging on over HTTP(S), sends the

ticket only to the server that created the
login/ticket_only_to_host
ticket.
Available as of SAP Basis 4.6D

Other Login Parameters:

Parameters Explanation

login/disable_cpic Refuse incoming connections of type CPIC

Controls the emergency user SAP* (SAP

login/no_automatic_user_sapstar
Notes 2383 and 68048)

Specifies the default client. This client is

login/system_client automatically filled in on the system logon
screen. Users can type in a different client.

Specifies the exactness of the logon

login/update_logon_timestamp timestamp.
Available as of SAP Basis 4.6
 Other User Parameters

Parameters Explanation

Defines the maximum idle time for a user in

seconds (applies only for SAP GUI
rdisp/gui_auto_logout connections).
Default value: 0 (no restriction);
permissible values: any numerical value

Residual Risk or Inherent Risk? But is it Tolerable Risk?

Aug 13, 20156,950 views106 Likes32 CommentsShare on LinkedInShare on FacebookShare on Twitter
The issue of residual risk and how it differs from inherent risk is something that has been raised quite a lot lately, so I
thought it might be an idea to spend some time posting an answer rather than answering a post!

I want to focus on the significance of the word residual in respect to risk and not on the definition of the word risk,
which has received more than enough attention of late.

ISO standards 31000 and 27001 both define residual risk as the risk remaining after 'risk treatment'. COSO 's Integrated
Internal Control Framework (2013) defines it in the context of objectives as 'the risk to the achievement of objectives
that remains after managements responses have been developed and implemented' and the COSO Enterprise Risk
Management Framework (2004) says it's the risk remaining after management's response to the risk.

Anyway, these are pretty much the leading official definitions of residual risk. I prefer to focus more on controls and
define it as follows:

Definition of Residual Risk (my version, subject to change):

Residual risk is the modified risk after internal controls have been implemented and monitored and the effect of their
findings considered.

If therefore residual risk is risk that's been modified, what did we have before modification? The answer is, the initial
value inherent in the risk from the start - a level of risk given following evaluation by someone suitably qualified for
such a task, like a risk manager, chief compliance officer or executive manager. The method involved in that evaluation
does not change the fact that it is evaluated or inherent risk. What is important is that the risk is identified and
assessed responsibly and to the satisfaction of management.

I often use the term evaluation risk to describe this initial risk but the most widely accepted term is inherent risk. COSO
ERM describes inherent risk as the absence of any actions management might take to alter either the risks probability
or impact. Interestingly, ISO 31000 doesn't mention the term 'inherent risk' anywhere; it just calls it risk.

Definition of Inherent Risk (my version, subject to change):

Inherent risk is the level of risk before action is taken to manage it.

When you initially evaluate a risk, you are evaluating the inherent risk but at this stage the residual risk is still identical
to the inherent risk because no controls have yet been put in place (at least no new ones), let alone monitored. If we
manage or treat the risk, we will hopefully discover in future evaluations that the residual risk has dropped. Still,
whether it's inherent or residual risk you're talking about, it normally comprises a measure of probability (or
likelihood) and a measure of consequence (or impact).

Evaluating Performance of Risk Management

Now we've got inherent (initial) and residual (modified) risk values for probability and consequence, but what's
missing is an indication of whether the residual risk is acceptable or not; and this in turn would be a metric of how well
our risk management activity is working.

We tend to assume that managing risk is all about trying to lower it, but that may not necessarily be true. What about
a risk that is currently tolerable that we choose to manage to keep it that way? Or one that is not financially justified to
reduce? That brings me to another stage in the risk's evaluation - 'tolerable risk'.

Definition of Tolerable Risk (my version, subject to change)

Tolerable risk is the level of risk deemed acceptable

An Example of Inherent, Tolerable and Residual Risk

To keep it simple, we will look only at probability and not consequence. Take a look at the following steps:

You identified a risk: Employees will act maliciously.

You assess the current state of the risk. In your evaluation, the current or inherent risk probability is 3 (medium) on a
scale of 1-5 where 1 is the lowest and 5 the highest. So,inherent risk probability = 3 (medium). We haven't done
anything yet in the way of managing the risk. Therefore, right now, residual risk probability also = 3 (medium).
Can you lower the risk probability? Let's assume you can and you have some controls that can help you do it. We will
assume that nothing other than 1 (very low) is acceptable so you define your tolerable risk probability as 1. Your
mission is to get residual risk probability down from 3 to 1 therefore, tolerable risk probability = 1 (very low)
Recapping 2 and 3, we get:
Inherent risk probability = 3 (medium)
Residual risk probability = 3 (medium)
Tolerable risk probability = 1 (very low)
Now go and implement those internal controls you devised. This constitutes your risk management activity or risk
treatment. Some might be immediate, but others could take months to get adopted. For example, maybe you started
social activities among the employees to improve working relationships but didn't yet update the employee rules and
regulations guide.
It's now time to reevaluate the risk in light of the controls and this gives you your residual risk probability. Let's assume
you conclude that the probability that employees will act maliciously has dropped from 3 (medium) to 2 (low). This is
better, but the risk level has still not reached the level you set as that which management is prepared to tolerate.
Some months later, you perform another evaluation after the employee rules and regulations guide has been updated
and distributed and you see that the employee social activity is working great. If your current assessment indicates
that the probability of employees acting maliciously as a result of your controls is 1 (very low), then it has reached the
tolerable level you set previously. You can announce that the risk is under control and you might even get offered a
drink from the boardroom cocktail cabinet!
There are many other considerations like a method of monitoring the control performance and changes to inherent
risk due to changing circumstances. Another question I hinted at earlier is whether inherent risk evaluations should
include the effect of 'old' controls already in place. I'll save that stuff for later!

You can see an expanded version of this post on my blog: http://www.objectivecontrols.com/blog_2015/2015-08-

12_objective_blog.html

Risk Management
Risk Assessment
Internal Controls
Neil Leigh
Written by
Neil LeighFollow
LikeCommentShare on LinkedInShare on FacebookShare on Twitter106 likes32 comments
Add your comment

Add your comment

Popular
Kaevin Rombaut Kaevin Rombaut
Non-Financial Risk Manager - Direct Channels at ING Belgium
Interesting article and definition wise certainly the object of discussion. In my personal view we need to make a
distinction between 2 aspects of risk: - risk appetite and tolerable risk level: the risk an organisation sets as a target (=
risk appetite) and maximum acceptable (= tolerable) by which it want to operate. These are determined by taking
distance from what 'we currently have' (as objective as possible). I however must say that the difference is debatable...
- inherent - current - residual: these levels are based on risk assessments of the actual situation Although
organisations can perfectly function without all those risk level denominators, I will try to follow your reasoning and
denominators. As a sidenote, I see less value in determining inherent risk besides the fact that it can serve to decide
whether controls should uberhaupt be put in place. E.g if inherent risk is very low, will it add value to an organisation
to put a control in place on a risk which inherently is already neglectable... The current risk or actual risk is the factor
with which comparisons to risk appetite and tolerable risk can be made on existing situations. The current risk should
be within your predetermined tolerable risk at all times and prefereably within your risk appetite: - If current risk is
above your tolerable risk, actions must be taken - if current risk is above your risk appetite, actions should be taken
For residual risk: residual risk = current risk - actions planned to reduce the risk Therefore, residual risk should always
be within risk appetite. As discussions on this topic will most likely continue for some time, please feel free to
comment