Information technology Networking
ICTNWK510 Develop, implement and evaluate system and
application security
Learner Materials and Assessment Tasks
1|Page
Table of Contents
About ICTNWK510 Develop, implement and evaluate system and application security .................... 5
Identify enterprise ICT system or application security policies .......................................................... 10
Activity 1 ............................................................................................................................................... 17
Identify security requirements for the ICT system or application...................................................... 38
Activity 2 ............................................................................................................................................... 49
Write an ICT system or application security plan according to the enterprise and ICT system or
application security policies................................................................................................................. 58
Activity 3 ............................................................................................................................................... 90
Identify standards against which to engineer the ICT system or application .................................... 95
Activity 4 ............................................................................................................................................... 99
Identify criteria for performing risk based audits against the ICT system or application ............... 102
Activity 5 ............................................................................................................................................. 115
Develop processes and procedures to mitigate the introduction of vulnerabilities during the
engineering process ........................................................................................................................... 129
Activity 6 ............................................................................................................................................. 144
Integrate applicable information security requirements, controls, processes, and procedures into
ICT system and application design specifications according to established requirements ............. 158
Execute enterprise and ICT system or application security policies ................................................ 169
Activity 7 ............................................................................................................................................. 174
Apply and verify compliance with identified standards against which to engineer the ICT system or
application .......................................................................................................................................... 177
Activity 8 ............................................................................................................................................. 181
Perform processes and procedures to mitigate the introduction of vulnerabilities during the
engineering process ........................................................................................................................... 184
Perform secure configuration management practices ..................................................................... 188
Activity 9 ............................................................................................................................................. 198
Validate that the engineered ICT system and application security controls meet the specified
requirements ...................................................................................................................................... 202
Re-engineer security controls to mitigate vulnerabilities identified during the operations phase 204
Ensure integration of information security practices throughout the SDLC process ...................... 204
Document ICT system or application security controls addressed within the system .................... 205
Practise secure coding ........................................................................................................................ 206
Activity 10 ........................................................................................................................................... 210
Review new and existing risk management technologies to achieve an optimal enterprise risk
posture................................................................................................................................................ 213
2|Page
Review new and existing ICT security technologies to support secure engineering across the SDLC
phases ................................................................................................................................................. 214
Continually assess effectiveness of the information system controls based on risk management
practices and procedures ................................................................................................................... 215
Assess and evaluate system compliance with corporate policies and architectures ...................... 225
Assess system maturation and readiness for promotion to the production stage ......................... 228
Collect lessons learned from integration of information security into the SDLC and use to identify
improvement actions ......................................................................................................................... 231
Activity 11 ........................................................................................................................................... 238
Collect, analyse and report performance measures ......................................................................... 240
Activity 12 ........................................................................................................................................... 241
Additional Reference Materials
Students should have access to:
AS/NZS ISO/IEC 38500:2010
ISO/IEC 38500:2008
Australian/New Zealand Standard™
Corporate governance of information technology
3|Page
seDownload from:
http://www.professionalsaustralia.org.au/information-technology/wpcontent/uploads/sites/41/2014/11/Standards-Australia-Corporate-Governance-of-IT1.pdf
4|Page
About ICTNWK510 Develop, implement and evaluate system and
application security
Application
This unit describes the skills and knowledge required to develop, implement and evaluate
information security in an information and communications technology (ICT) system or application
during the system development life cycle (SDLC), prior to the operations and maintenance phase.
It applies to individuals with excellent information and communications technology (ICT) expertise
who are working as network managers and are required to handle system and application security
from the development phase through implementation to evaluation.
No licensing, legislative or certification requirements apply to this unit at the time of publication.
Unit Sector
Networking
Elements and Performance Criteria
ELEMENT
PERFORMANCE CRITERIA
Elements describe the
Performance criteria describe the performance needed to
essential outcomes.
demonstrate achievement of the element.
1. Develop system and
1.1 Identify enterprise ICT system or application security policies
application security
1.2 Identify security requirements for the ICT system or application
1.3 Write an ICT system or application security plan according to
the enterprise and ICT system or application security policies
1.4 Identify standards against which to engineer the ICT system or
application
1.5 Identify criteria for performing risk based audits against the ICT
system or application
1.6 Develop processes and procedures to mitigate the introduction
of vulnerabilities during the engineering process
1.7 Integrate applicable information security requirements,
controls, processes, and procedures into ICT system and application
design specifications according to established requirements
5|Page
2. Implement system and
application security
2.1 Execute enterprise and ICT system or application security
policies
2.2 Apply and verify compliance with identified standards against
which to engineer the ICT system or application
2.3 Perform processes and procedures to mitigate the introduction
of vulnerabilities during the engineering process
2.4 Perform secure configuration management practices
2.5 Validate that the engineered ICT system and application
security controls meet the specified requirements
2.6 Re-engineer security controls to mitigate vulnerabilities
identified during the operations phase
2.7 Ensure integration of information security practices throughout
the SDLC process
2.8 Document ICT system or application security controls addressed
within the system
3. Evaluate system and
application security
2.9 Practise secure coding
3.1 Review new and existing risk management technologies to
achieve an optimal enterprise risk posture
3.2 Review new and existing ICT security technologies to support
secure engineering across the SDLC phases
3.3 Continually assess effectiveness of the information system
controls based on risk management practices and procedures
3.4 Assess and evaluate system compliance with corporate policies
and architectures
3.5 Assess system maturation and readiness for promotion to the
production stage
3.6 Collect lessons learned from integration of information security
into the SDLC and use to identify improvement actions
3.7 Collect, analyse and report performance measures
6|Page
Foundation Skills
This section describes language, literacy, numeracy and employment skills incorporated in the
performance criteria that are required for competent performance.
Skill
Learning
Performance Criteria
3.6
Description
 Builds on prior knowledge and experience
to clarify, extend understanding and
contribute to ongoing organisational
improvement
Reading
1.1-1.4, 1.7, 2.2, 3.4,
3.7

Gathers, interprets and analyses technical
and regulatory information to determine
requirements according to client needs
Writing
1.3, 2.8, 3.7

Uses factual information and industry
related terminology to produce workplace
documents
Oral
Communication
3.7

Conveys information about performance
measures clearly, using specific and
relevant language suitable to audience
Uses listening and questioning techniques
to confirm understanding

Navigate the
world of work
1.1, 1.3, 1.7

Takes full responsibility for identifying and
considering relevant policies and legislative
requirements in the development of system
security processes
Get the work done
1.5-1.7, 2.1, 2.3-2.7,
2.9, 3.1-3.5

Demonstrates a sophisticated
understanding of principles, concepts,
language and practices associated with the
digital world and uses these to troubleshoot
and reduce risks
Uses digital tools to access and organise
complex data and analyse multiple sources
of information for strategic purposes
Is acutely aware of the importance of
understanding, monitoring and controlling
access to digitally stored and transmitted
information
Uses a combination of formal and logical
planning processes and an increasingly
intuitive understanding of context to
identify relevant information and risks



7|Page

Unit Mapping Information
Code and title
Code and title
current version
ICTNWK510
Develop, implement
and evaluate system
and application
security
previous version
ICANWK510A
Develop, implement
and evaluate system
and application
security
Makes a range of critical decisions in
relatively complex situations, taking a range
of constraints into account
Comments
Equivalence
status
Updated to meet Standards for Equivalent unit
Training Packages
Assessment requirements
Modification History
Release
Release 1
Comments
This version first released with ICT Information and
Communications Technology Training Package Version 1.0.
Performance Evidence
Evidence of the ability to:





create an information and communications technology (ICT) system or application security
plan
implement system and application security
apply and verify compliance with the identified standards
practise secure coding practices
assess and evaluate system compliance.
Note: If a specific volume or frequency is not stated, then evidence must be provided at least once.
Knowledge Evidence
To complete the unit requirements safely and effectively, the individual must:





summarise a range of programming languages, including those used by the organisation
summarise best practice in application of language syntax rules
explain data structures
outline graphical user interfaces (GUIs)
summarise small-size application development
8|Page


identify and summarise the legislation, regulations and codes of practice that impact on
network security
describe the risk assessment process required in evaluating system vulnerabilities, including:




risk mitigation
security control selection
implementation and evaluation process
software security standards compliance.
9|Page
Identify enterprise ICT system or application security policies
System Development Life Cycle Phases1
1- System Planning
The Planning phase is the most crucial step in creating a successful system, during this phase you
decide exactly what you want to do and the problems you’re trying to solve, by:

Defining the problems, the objectives and the resources such as personnel and costs.

Studying the ability of proposing alternative solutions after meeting with clients, suppliers,
consultants and employees.

Studying how to make your product better than your competitors’.
After analyzing this data you will have three choices: develop a new system, improve the current
system or leave the system as it is.
2- System Analysis
The end-user’s requirements should be determined and documented, what their expectations are
for the system, and how it will perform. A feasibility study will be made for the project as well,
involving determining whether it’s organizationally, economically, socially, technologically feasible.
1
Source: Airbrake, as at https://airbrake.io/blog/sdlc/what-is-system-development-life-cycle, as on 10th May,
2017.
10 | P a g e
it’s very important to maintain strong communication level with the clients to make sure you have a
clear vision of the finished product and its function.
3- System Design
The design phase comes after a good understanding of customer’s requirements, this phase defines
the elements of a system, the components, the security level, modules, architecture and the
different interfaces and type of data that goes through the system.
A general system design can be done with a pen and a piece of paper to determine how the system
will look like and how it will function, and then a detailed and expanded system design is produced,
and it will meet all functional and technical requirements, logically and physically.
4- Implementation and Deployment
This phase comes after a complete understanding of system requirements and specifications, it’s the
actual construction process after having a complete and illustrated design for the requested system.
In the Software Development Life Cycle, the actual code is written here, and if the system contains
hardware, then the implementation phase will contain configuration and fine-tuning for the
hardware to meet certain requirements and functions.
In this phase, the system is ready to be deployed and installed in customer’s premises, ready to
become running, live and productive, training may be required for end users to make sure they know
how to use the system and to get familiar with it, the implementation phase may take a long time
and that depends on the complexity of the system and the solution it presents.
5- System Testing and Integration
Bringing different components and subsystems together to create the whole integrated system, and
then Introducing the system to different inputs to obtain and analyze its outputs and behavior and
the way it functions. Testing is becoming more and more important to ensure customer’s
satisfaction, and it requires no knowledge in coding, hardware configuration or design.
Testing can be performed by real users, or by a team of specialized personnel, it can also be
systematic and automated to ensure that the actual outcomes are compared and equal to the
predicted and desired outcomes.
6- System Maintenance
In this phase, periodic maintenance for the system will be carried out to make sure that the system
won’t become obsolete, this will include replacing the old hardware and continuously evaluating
system’s performance, it also includes providing latest updates for certain components to make sure
it meets the right standards and the latest technologies to face current security threats.
11 | P a g e
These are the main six phases of the System Development Life Cycle, and it’s an iterative process for
each project. It’s important to mention that excellent communication level should be maintained
with the customer, and Prototypes are very important and helpful when it comes to meeting the
requirements. By building the system in short iterations; we can guarantee meeting the customer’s
requirements before we build the whole system.
Many models of system development life cycle came up from the idea of saving effort, money and
time, in addition to minimizing the risk of not meeting the customer’s requirement at the end of
project, some of these models are SDLC Iterative Model, and SDLC Agile Model.
In business, a security policy is a document that states in writing how a company plans to protect the
company's physical and information technology (IT) assets. A security policy is often considered to
be a "living document", meaning that the document is never finished, but is continuously updated as
technology and employee requirements change. A company's security policy may include an
acceptable use policy, a description of how the company plans to educate its employees about
protecting the company's assets, an explanation of how security measurements will be carried out
and enforced, and a procedure for evaluating the effectiveness of the security policy to ensure that
necessary corrections will be made2.
ICT security policies by enterprise size, sector and country3
The existence of an ICT security policy in an enterprise means that the enterprise is aware of the
importance of its ICT systems and the relevant potential risks. Moreover, the existence of an ICT
security policy would imply an enterprise's strategy to safeguard data and ICT systems as well as
mandatory obligations for all employees. In 2015, 32 % of enterprises in the EU-28 had a formally
defined ICT security policy; shares of over 45 % were registered in Sweden and Portugal (51 % and
49 % respectively). In the context of this article, a formally defined policy should refer to an
assessment of ICT security risks in terms of likelihood of occurrence of incidents and their possible
impact on the operations of the enterprise. In addition, a policy should describe the various actors
and their responsibilities in relation to incident handling and possible contingency plans.
Figure 1 shows that the share of large enterprises that had a formally defined ICT security policy was
almost three times the share of small ones. The highest proportions of enterprises having such a
policy in the EU-28 was reported by enterprises in the sector of Information and communication
activities (60 %) as well as by enterprises with Professional, scientific and technical activities (49 %)
(Figure 2). The lowest proportions were registered in the sectors of Construction (20 %), Real estate
(25 %) and Transportation and storage (26 %) .
It is assumed that the existence of ICT security policy and the frequency of reviewing it is positively
correlated to the readiness of the enterprises to report ICT security incidents. Out of all EU
2
Source: Tech Target, as at http://searchsecurity.techtarget.com/definition/security-policy, as on 8th May,
2017.
3
Source: Eurostat, as at http://ec.europa.eu/eurostat/statisticsexplained/index.php/ICT_security_in_enterprises, as on 8th May, 2017.
12 | P a g e
enterprises that reported having an ICT security policy (32 %) the majority of them reported having
defined or reviewed their policy within the last 12 months (20 %) (Figure 3).
The highest percentage of enterprises that most recently defined or reviewed their policy was
reported in Ireland (30 %), Croatia and Portugal (both 29 %). Some (40 %) of enterprises in
Information and communication activities – highest proportion among all economic activities –
reported having defined or reviewed their ICT policy in the last 12 months (Figure 4).
Types of risks
The risk of destruction or corruption of data due to an attack or some other unexpected incident is
the risk mostly addressed by enterprises’ ICT security policies.
The three types of risks addressed by enterprises having a formally defined ICT security policy
correspond essentially to the core elements of the ICT security definition, i.e. integrity,
confidentiality and availability of data and systems. These elements are further described in the
following section of this article.
The highest percentage of enterprises with a formally defined ICT security policy addressing the risks
of destruction or corruption of data due to an attack or some other unexpected incident was
reported in Portugal (44 %). Similarly enterprises in Portugal reported the second highest percentage
with a formally defined ICT security policy addressing the risks of unavailability of ICT services due to
an attack from outside (e.g. Denial of Service attack) (35 %).
The highest percentage of enterprises with a formally defined ICT security policy addressing the risks
of disclosure of confidential data due to intrusion, pharming, phishing attacks or by accident was
reported in Ireland (39 %). In addition, enterprises in Ireland reported the highest percentage with a
formally defined ICT security policy addressing all the above mentioned risks (35 %).
Data sources and availability
Source: Data presented in this article are based on the results of the 2015 Community survey on 'ICT
usage and e-commerce in enterprises'. Statistics were obtained from surveys in enterprises
conducted by National Statistical Authorities in the first months of 2015.
13 | P a g e
Sample: Some 148 800 enterprises, with 10 or more persons employed, out of 1.5 million in EU-28
were surveyed. Out of these 1.5 million enterprises approximately 83 % were enterprises with 10-49
persons employed, 14 % with 50-249 and 3 % with 250 or more.
Symbols: Data in tables shown as ‘:’ refer to data that are unavailable, unreliable, confidential or not
applicable. Unreliable data are included in the calculation of European aggregates. Data presented in
this article may differ from the data in the database on account of updates made after the data
extractions used for this article.
Main concepts: The surveys' reference period was the current situation of the survey period or for
some questions (like e.g. e-commerce) the year 2014. The observation statistical unit is the
enterprise, as defined in the Regulation 696/1993 of 15 March 1993. The survey covered enterprises
with at least 10 persons employed. Economic activities correspond to the classification NACE
Revision 2. The sectors covered are manufacturing, electricity, gas and steam, water supply,
construction, wholesale and retail trades, repair of motor vehicles and motorcycles, transportation
and storage, accommodation and food service activities, information and communication, real
estate, professional, scientific and technical activities, administrative and support activities and
repair of computers and communication equipment. Enterprises are broken down by size; small (1049), medium (50-249) and large enterprises (250 or more persons employed).
ICT-related security incidents affect the ICT system of an enterprise and may cause different
problems. Therefore, the following security risks were expected to be addressed by the enterprises'
ICT security policies :

Destruction or corruption of data due to hardware or software failures refers to issues of
data integrity caused by hardware or software failures, e.g. crashes of servers or hard disks
due to hardware failures or crashes of servers due to software failures, e.g. erroneous
updates.
Unavailability of ICT services due to attack from outside refers to attempts from outside to
make an information system resource unavailable to its intended users. One aim of these
attacks is to prevent an internet site or service from functioning efficiently, e.g. websites of
banks, credit card payment gateways.
Disclosure of confidential data due to intrusion, pharming, phishing attacks refers to an
attempt to get confidential information on persons, staff or clients, intellectual property or
other confidential information. Intrusion is an attempt to bypass security controls on an
information system by viruses, worms, Trojan horses etc. Phishing is a criminally fraudulent
attempt to acquire sensitive information such as usernames, passwords and credit card
details by masquerading as a trustworthy entity in an electronic communication. Pharming is
an attack which redirects the traffic of a website to another, bogus website in order to
acquire sensitive information.



The evolution of computer networks has made the sharing of information ever more
prevalent. Information is now exchanged at the rate of trillions of bytes per millisecond,
daily numbers that might extend beyond comprehension or available nomenclature. A
proportion of that data is not intended for sharing beyond a limited group and much data
is protected by law or intellectual property.
14 | P a g e




An information security policy endeavors to enact those protections and limit the
distribution of data not in the public domain to authorized recipients4.
Every organization needs to protect its data and also control how it should be distributed
both within and without the organizational boundaries. This may mean that information
may have to be encrypted, authorized through a third party or institution and may have
restrictions placed on its distribution with reference to a classification system laid out in
the information security policy.
An example of the use of an information security policy might be in a data storage facility
which stores database records on behalf of medical facilities. These records are sensitive
and cannot be shared, under penalty of law, with any unauthorized recipient whether a
real person or another device. An information security policy would be enabled within the
software that the facility uses to manage the data they are responsible for. In addition,
workers would generally be contractually bound to comply with such a policy and would
have to have sight of it prior to operating the data management software.
A business might employ an information security policy to protect its digital assets and
intellectual rights in efforts to prevent theft of industrial secrets and information that
could benefit competitors.
A typical security policy might be hierarchical and apply differently depending on whom
they apply to. For example, the secretarial staff who type all the communications of an
organization are usually bound never to share any information unless explicitly
authorized, whereby a more senior manager may be deemed authoritative enough to
decide what information produced by the secretaries can be shared, and to who, so they
are not bound by the same information security policy terms. To cover the whole
organization therefore, information security policies frequently contain different
specifications depending upon the authoritative status of the persons they apply to.

A good security policy takes into consideration the mission of the organization, the critical assets
requiring protection, the threats posed and the mitigating risks against known vulnerabilities. These
are all parts of a risk assessment that includes a business-impact analysis, which identifies the
weaknesses, the critical assets and the effect on the company if a vulnerability were exploited5.
Developing a security policy isn't a daunting task once the scope is identified using this simple
explanation. The challenges are in defining the scope and writing a policy that can be embraced by
other areas of the organization.
By definition, the policy is the high-level document that's used to guide the formulation of
procedures and guidelines. The policy answers the question of "What should be done and by
whom?" The procedures and guidelines answer the question of "How should it be done?"
4
Source: Technopedia, as at https://www.techopedia.com/definition/24838/information-security-policy, as on
8th May, 2017.
5
Source: Computer World, as at http://www.computerworld.com/article/2569303/security0/how-to-developan-enterprise-security-policy.html, as on 8th May, 2017.
15 | P a g e
Below are some tips for developing a comprehensive enterprise security policy. It's a checklist for
any policy wonk given the responsibility of putting the document together.
1. Know your organization. Without a realistic understanding of the organizational structure -the players, the environment, the mission, goals and objectives -- it's exceedingly difficult to
write a policy that will fit. Therefore, knowing the lay of the land -- the hierarchy and the
roles and responsibilities of different areas -- is very important.
2. Define the scope and the agenda. What will the policy cover? This should be stated upfront
in the policy document. Equally important is what it won't cover. If you can derive both, it
will be meaningful to the people who need to translate the policy to practical procedures
and/or guidelines.
3. Know your target audience. Who are the stakeholders for the various sections of the
document? Who will be reading and signing off on it? The CEO, CIO and CISO are normally
the key stakeholders, and each has a specific agenda that should be addressed. For the CEO,
it would be the areas derived from the business-impact analysis; for the CIO, it would be the
overall enterprise architecture and infrastructure that aligns and enables the CEO and the
organizational mission; and for the CISO, it should address the critical infrastructure and
assets, along with risk, vulnerability and mitigation focus.
4. Stay high-level, general and broad. These are critical points that need to be remembered as
each policy statement is written. Going too far down in the weeds leads to the area of
procedures, so it's important to keep the policy statements at the appropriate level and
aligned with the mission.
5. Ensure that it can be easily translated to procedures and guidelines by the appropriate
areas. Try a small sample, imagine the area to which the policy might apply and see if you
can easily derive a procedure or guideline. After all, you might be asked for some examples
down the road by less-experienced managers.
6. Keep weaknesses and organizational deficiencies in mind so the policy can address specific
areas while staying aligned with your goals. Recognize the gaps and try to bridge them
through policies. Keep the mission and business-impact analysis in mind. These are critical to
effective policies that supplant the gaps in organizational functionality.
7. Be aware of external drivers. Depending on your industry, there may be regulatory
requirements or cross-cutting laws. The policy should address the requirements to ensure
compliance and make your organization a model.
8. Be realistic. If you can get a first cut past the approving authorities, it's a step in the right
direction. Policies can never be static because the environment and organizational
operations are always changing. Companies on the leading edge are dynamic in nature, and
gaining competitive advantage requires continuous change and improvement. A policy that
addresses 90% of the needs and is implemented is better than one that aims for 100% but
never gets out of draft mode.
9. Ensure version control and backups. This seems like common sense, but you'd be surprised
at how many organizations don't maintain tight version control, including documented
procedures for modifications along with a good single backup strategy. You never want to
end up hunting for the most current policy document, nor should you ever question its
integrity. This in itself may require a policy.
16 | P a g e
10. Avoid controversy. This of course depends on how well the policy is rolled out and what
changes are made. If change is required, do it incrementally. It hurts less. Having the backing
of senior executive leadership is also important in the event that critical gaps require
immediate change.
11. Wear a white hat. Remember, the whole reason for developing security policies is to benefit
the organization and its personnel. If you are given the task of getting the job done, try to
get acceptance from the key managers sooner rather than later. An effective policy
development effort has collaboration written all over it. And, done properly, it can even be
fun.
12. Finally, don't forget to smile and keep your sense of humor. It can be an intense effort, but
by using proven project management methods, including milestones and timing, you can
ensure that the important pieces are addressed first and that stress is minimized. It comes
down to having a good road map, a strategy and a flashlight.
Activity 1
Where in an organisation are you likely to find its ICT security policy?
17 | P a g e
Activity 1
18 | P a g e
Sample Policies6
Acquisition Assessment Policy
1. Overview
The process of integrating a newly acquired company can have a drastic impact on the security
poster of either the parent company or the child company. The network and security infrastructure
of both entities may vary greatly and the workforce of the new company may have a drastically
different culture and tolerance to openness. The goal of the security acquisition assessment and
integration process should include:





Assess company’s security landscape, posture, and policies
Protect both <Company Name> and the acquired company from increased security risks
Educate acquired company about <Company Name> policies and standard
Adopt and implement <Company Name> Security Policies and Standards
Integrate acquired company
6
Source: SANS, as at https://www.sans.org/security-resources/policies/network-security#acquisitionassessment-policy, as on 8th May, 2017.
19 | P a g e

Continuous monitoring and auditing of the acquisition
2. Purpose
The purpose of this policy is to establish Infosec responsibilities regarding corporate acquisitions,
and define the minimum security requirements of an Infosec acquisition assessment.
3. Scope
This policy applies to all companies acquired by <Company Name> and pertains to all systems,
networks, laboratories, test equipment, hardware, software and firmware, owned and/or operated
by the acquired company.
4. Policy
4.1 General
Acquisition assessments are conducted to ensure that a company being acquired by <Company
Name> does not pose a security risk to corporate networks, internal systems, and/or
confidential/sensitive information. The Infosec Team will provide personnel to serve as active
members of the acquisition team throughout the entire acquisition process. The Infosec role is to
detect and evaluate information security risk, develop a remediation plan with the affected parties
for the identified risk, and work with the acquisitions team to implement solutions for any identified
security risks, prior to allowing connectivity to <Company Name>'s networks. Below are the
minimum requirements that the acquired company must meet before being connected to the
<Company Name> network.
4.2 Requirements
4.2.1 Hosts
4.2.1.1 All hosts (servers, desktops, laptops) will be replaced or re-imaged with a <Company
Name> standard image or will be required to adopt the minimum standards for end
user devices.
4.2.1.2 Business critical production servers that cannot be replaced or re-imaged must be
audited and a waiver granted by Infosec.
4.2.1.3 All PC based hosts will require <Company Name> approved virus protection before
the network connection.
4.2.2
Networks
4.2.2.1 All network devices will be replaced or re-imaged with a <Company Name> standard
image.
4.2.2.2 Wireless network access points will be configured to the <Company Name> standard.
4.2.3
Internet
4.2.3.1 All Internet connections will be terminated.
4.2.3.2 When justified by business requirements, air-gapped Internet connections require
Infosec review and approval.
4.2.4 Remote Access
4.2.4.1 All remote access connections will be terminated.
20 | P a g e
4.2.4.2 Remote access to the production network will be provided by <Company Name>.
4.2.5
Labs
4.2.5.1 Lab equipment must be physically separated and secured from non-lab areas.
4.2.5.2 The lab network must be separated from the corporate production network with a
firewall between the two networks.
4.2.5.3 Any direct network connections (including analog lines, ISDN lines, T1, etc.) to
external customers, partners, etc., must be reviewed and approved by the Lab
Security Group (LabSec).
4.2.5.4 All acquired labs must meet with LabSec lab policy, or be granted a waiver by
LabSec.
4.2.5.5 In the event the acquired networks and computer systems being connected to the
corporate network fail to meet these requirements, the <Company Name> Chief
Information Officer (CIO) must acknowledge and approve of the risk to <Company
Name>'s networks
5. Policy Compliance
5.1 Compliance Measurement
The Infosec team will verify compliance to this policy through various methods, including but not
limited to, business tool reports, internal and external audits, and feedback to the policy owner.
5.2 Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
5.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.
6 Related Standards, Policies and Processes
None.
7 Definitions and Terms
The following definition and terms can be found in the SANS Glossary located at:
https://www.sans.org/security-resources/glossary-of-terms/

Business Critical Production Server
21 | P a g e
8
Revision History
Date of Change
Responsible
Summary of Change
Bluetooth Baseline Requirements Policy
1. Overview
Bluetooth enabled devices are exploding on the Internet at an astonishing rate. At the range of
connectivity has increased substantially. Insecure Bluetooth connections can introduce a number of
potential serious security issues. Hence, there is a need for a minimum standard for connecting
Bluetooth enable devices.
2. Purpose
The purpose of this policy is to provide a minimum baseline standard for connecting Bluetooth
enabled devices to the <Company Name> network or <Company Name> owned devices. The intent
of the minimum standard is to ensure sufficient protection Personally Identifiable Information (PII)
and confidential <Company Name> data.
3. Scope
This policy applies to any Bluetooth enabled device that is connected to <Company Name> network
or owned devices.
4. Policy
4.1 Version
No Bluetooth Device shall be deployed on <Company Name> equipment that does not meet a
minimum of Bluetooth v2.1 specifications without written authorization from the Infosec Team. Any
Bluetooth equipment purchased prior to this policy must comply with all parts of this policy except
the Bluetooth version specifications.
4.2 Pins and Pairing
When pairing your Bluetooth unit to your Bluetooth enabled equipment (i.e. phone, laptop, etc.),
ensure that you are not in a public area where you PIN can be compromised.
If your Bluetooth enabled equipment asks for you to enter your pin after you have initially paired it,
you must refuse the pairing request and report it to Infosec, through your Help Desk, immediately.
4.3 Device Security Settings
22 | P a g e





All Bluetooth devices shall employ ‘security mode 3’ which encrypts traffic in both
directions, between your Bluetooth Device and its paired equipment.
Use a minimum PIN length of 8. A longer PIN provides more security.
Switch the Bluetooth device to use the hidden mode (non-discoverable)
Only activate Bluetooth only when it is needed.
Ensure device firmware is up-to-date.
4.4 Security Audits
The Infosec Team may perform random audits to ensure compliancy with this policy. In the process
of performing such audits, Infosec Team members shall not eavesdrop on any phone conversation.
4.5 Unauthorized Use
The following is a list of unauthorized uses of <Company Name>-owned Bluetooth devices:
 Eavesdropping, device ID spoofing, DoS attacks, or any form of attacking other Bluetooth
enabled devices.
 Using <Company Name>-owned Bluetooth equipment on non-<Company Name>-owned
Bluetooth enabled devices.
 Unauthorized modification of Bluetooth devices for any purpose.
4.6 User Responsibilities
 It is the Bluetooth user's responsibility to comply with this policy.
 Bluetooth mode must be turned off when not in use.
 PII and/or <Company Name> Confidential or Sensitive data must not be transmitted or
stored on Bluetooth enabled devices.
 Bluetooth users must only access <Company Name> information systems using
approved Bluetooth device hardware, software, solutions, and connections.
 Bluetooth device hardware, software, solutions, and connections that do not meet the
standards of this policy shall not be authorized for deployment.
 Bluetooth users must act appropriately to protect information, network access,
passwords, cryptographic keys, and Bluetooth equipment.
 Bluetooth users are required to report any misuse, loss, or theft of Bluetooth devices or
systems immediately to Infosec.
5. Policy Compliance
8.1 Compliance Measurement
The Infosec Team will verify compliance to this policy through various methods, including but not
limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits,
and feedback to the policy owner.
8.2 Exceptions
Any exception to the policy must be approved by the Infosec Team in advance.
8.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.
23 | P a g e
9 Related Standards, Policies and Processes
None.
10 Definitions and Terms
None.
11 Revision History
Date of Change
Responsible
Summary of Change
Remote Access Policy
1. Overview
Remote access to our corporate network is essential to maintain our Team’s productivity, but in
many cases this remote access originates from networks that may already be compromised or are at
a significantly lower security posture than our corporate network. While these remote networks are
beyond the control of Hypergolic Reactions, LLC policy, we must mitigate these external risks the
best of our ability.
2. Purpose
The purpose of this policy is to define rules and requirements for connecting to <Company Name>'s
network from any host. These rules and requirements are designed to minimize the potential
exposure to <Company Name> from damages which may result from unauthorized use of <Company
Name> resources. Damages include the loss of sensitive or company confidential data, intellectual
property, damage to public image, damage to critical <Company Name> internal systems, and fines
or other financial liabilities incurred as a result of those losses.
3. Scope
This policy applies to all <Company Name> employees, contractors, vendors and agents with a
<Company Name>-owned or personally-owned computer or workstation used to connect to the
<Company Name> network. This policy applies to remote access connections used to do work on
behalf of <Company Name>, including reading or sending email and viewing intranet web resources.
This policy covers any and all technical implementations of remote access used to connect to
<Company Name> networks.
4. Policy
It is the responsibility of <Company Name> employees, contractors, vendors and agents with remote
access privileges to <Company Name>'s corporate network to ensure that their remote access
connection is given the same consideration as the user's on-site connection to <Company Name>.
24 | P a g e
General access to the Internet for recreational use through the <Company Name> network is strictly
limited to <Company Name> employees, contractors, vendors and agents (hereafter referred to as
“Authorized Users”). When accessing the <Company Name> network from a personal computer,
Authorized Users are responsible for preventing access to any <Company Name> computer
resources or data by non-Authorized Users. Performance of illegal activities through the <Company
Name> network by any user (Authorized or otherwise) is prohibited. The Authorized User bears
responsibility for and consequences of misuse of the Authorized User’s access. For further
information and definitions, see the Acceptable Use Policy.
Authorized Users will not use <Company Name> networks to access the Internet for outside business
interests.
For additional information regarding <Company Name>'s remote access connection options,
including how to obtain a remote access login, free anti-virus software, troubleshooting, etc., go to
the Remote Access Services website (company url).
4.1 Requirements
4.1.1 Secure remote access must be strictly controlled with encryption (i.e., Virtual Private
Networks (VPNs)) and strong pass-phrases. For further information see the Acceptable
Encryption Policy and the Password Policy.
4.1.2 Authorized Users shall protect their login and password, even from family members.
4.1.3 While using a <Company Name>-owned computer to remotely connect to <Company
Name>'s corporate network, Authorized Users shall ensure the remote host is not connected
to any other network at the same time, with the exception of personal networks that are
under their complete control or under the complete control of an Authorized User or Third
Party.
4.1.4 Use of external resources to conduct <Company Name> business must be approved in
advance by InfoSec and the appropriate business unit manager.
4.1.5 All hosts that are connected to <Company Name> internal networks via remote access
technologies must use the most up-to-date anti-virus software (place url to corporate
software site here), this includes personal computers. Third party connections must comply
with requirements as stated in the Third Party Agreement.
4.1.6 Personal equipment used to connect to <Company Name>'s networks must meet the
requirements of <Company Name>-owned equipment for remote access as stated in the
Hardware and Software Configuration Standards for Remote Access to <Company Name>
Networks.
5. Policy Compliance
11.1 Compliance Measurement
The Infosec Team will verify compliance to this policy through various methods, including but not
limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits,
and inspection, and will provide feedback to the policy owner and appropriate business unit
manager.
11.2 Exceptions
Any exception to the policy must be approved by Remote Access Services and the Infosec Team in
advance.
25 | P a g e
11.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.
6 Related Standards, Policies and Processes
Please review the following policies for details of protecting information when accessing the
corporate network via remote access methods, and acceptable use of <Company Name>’s network:





7
Acceptable Encryption Policy
Acceptable Use Policy
Password Policy
Third Party Agreement
Hardware and Software Configuration Standards for Remote Access to <Company Name>
Networks
Revision History
Date of Change
Responsible
Summary of Change
Remote Access Tools Policy
1. Overview
Remote desktop software, also known as remote access tools, provide a way for computer users and
support staff alike to share screens, access work computer systems from home, and vice versa.
Examples of such software include LogMeIn, GoToMyPC, VNC (Virtual Network Computing), and
Windows Remote Desktop (RDP). While these tools can save significant time and money by
eliminating travel and enabling collaboration, they also provide a back door into the <Company
Name> network that can be used for theft of, unauthorized access to, or destruction of assets. As a
result, only approved, monitored, and properly controlled remote access tools may be used on
<Company Name> computer systems.
2. Purpose
This policy defines the requirements for remote access tools used at <Company Name
3. Scope
This policy applies to all remote access where either end of the communication terminates at a
<Company Name> computer asset
26 | P a g e
4. Policy
All remote access tools used to communicate between <Company Name> assets and other systems
must comply with the following policy requirements.
4.1 Remote Access Tools
<Company Name> provides mechanisms to collaborate between internal users, with external
partners, and from non-<Company Name> systems. The approved software list can be obtained
from <link-to-approved-remote-access-software-list>. Because proper configuration is important for
secure use of these tools, mandatory configuration procedures are provided for each of the
approved tools.
The approved software list may change at any time, but the following requirements will be used for
selecting approved products:
a) All remote access tools or systems that allow communication to <Company Name>
resources from the Internet or external partner systems must require multi-factor
authentication. Examples include authentication tokens and smart cards that require an
additional PIN or password.
b) The authentication database source must be Active Directory or LDAP, and the
authentication protocol must involve a challenge-response protocol that is not susceptible
to replay attacks. The remote access tool must mutually authenticate both ends of the
session.
c) Remote access tools must support the <Company Name> application layer proxy rather than
direct connections through the perimeter firewall(s).
d) Remote access tools must support strong, end-to-end encryption of the remote access
communication channels as specified in the <Company Name> network encryption protocols
policy.
e) All <Company Name> antivirus, data loss prevention, and other security systems must not be
disabled, interfered with, or circumvented in any way.
All remote access tools must be purchased through the standard <Company Name> procurement
process, and the information technology group must approve the purchase.
5. Policy Compliance
7.1 Compliance Measurement
The Infosec team will verify compliance to this policy through various methods, including but not
limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits,
and feedback to the policy owner.
7.2 Exceptions
Any exception to the policy must be approved by the Infosec Team in advance.
7.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.
8
Related Standards, Policies and Processes
None.
27 | P a g e
9 Definitions and Terms
The following definition and terms can be found in the SANS Glossary located at:
https://www.sans.org/security-resources/glossary-of-terms/

Application layer proxy
10 Revision History
Date of Change
Responsible
Summary of Change
Router and Switch Security Policy
1. Overview
See Purpose.
2. Purpose
This document describes a required minimal security configuration for all routers and switches
connecting to a production network or used in a production capacity at or on behalf of <Company
Name>.
3. Scope
All employees, contractors, consultants, temporary and other workers at Cisco and its subsidiaries
must adhere to this policy. All routers and switches connected to Cisco production networks are
affected.
4. Policy
Every router must meet the following configuration standards:
1. No local user accounts are configured on the router. Routers and switches must use
TACACS+ for all user authentication.
2. The enable password on the router or switch must be kept in a secure encrypted form. The
router or switch must have the enable password set to the current production router/switch
password from the device’s support organization.
3. The following services or features must be disabled:
a. IP directed broadcasts
b. Incoming packets at the router/switch sourced with invalid addresses such as
RFC1918 addresses
28 | P a g e
4.
5.
6.
7.
8.
9.
10.
11.
c. TCP small services
d. UDP small services
e. All source routing and switching
f. All web services running on router
g. Cisco discovery protocol on Internet connected interfaces
h. Telnet, FTP, and HTTP services
i. Auto-configuration
The following services should be disabled unless a business justification is provided:
a. Cisco discovery protocol and other discovery protocols
b. Dynamic trunking
c. Scripting environments, such as the TCL shell
The following services must be configured:
a. Password-encryption
b. NTP configured to a corporate standard source
All routing updates shall be done using secure routing updates.
Use corporate standardized SNMP community strings. Default strings, such as public or
private must be removed. SNMP must be configured to use the most secure version of the
protocol allowed for by the combination of the device and management systems.
Access control lists must be used to limit the source and type of traffic that can terminate on
the device itself.
Access control lists for transiting the device are to be added as business needs arise.
The router must be included in the corporate enterprise management system with a
designated point of contact.
Each router must have the following statement presented for all forms of login whether
remote or local:
"UNAUTHORIZED ACCESS TO THIS NETWORK DEVICE IS PROHIBITED. You must have explicit
permission to access or configure this device. All activities performed on this device may be
logged, and violations of this policy may result in disciplinary action, and may be reported to
law enforcement. There is no right to privacy on this device. Use of this system shall
constitute consent to monitoring."
12. Telnet may never be used across any network to manage a router, unless there is a secure
tunnel protecting the entire communication path. SSH version 2 is the preferred
management protocol.
13. Dynamic routing protocols must use authentication in routing updates sent to neighbors.
Password hashing for the authentication string must be enabled when supported.
14. The corporate router configuration standard will define the category of sensitive routing and
switching devices, and require additional services or configuration on sensitive devices
including:
a. IP access list accounting
29 | P a g e
b. Device logging
c. Incoming packets at the router sourced with invalid addresses, such as RFC1918
addresses, or those that could be used to spoof network traffic shall be dropped
d. Router console and modem access must be restricted by additional security controls
5. Policy Compliance
10.1 Compliance Measurement
The Infosec team will verify compliance to this policy through various methods, including but not
limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits,
and feedback to the policy owner.
10.2 Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
10.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.
6 Related Standards, Policies and Processes
None.
7 Definitions and Terms
None.
8
Revision History
Date of Change
Responsible
Summary of Change
Wireless Communication Policy
1. Overview
With the mass explosion of Smart Phones and Tablets, pervasive wireless connectivity is almost a
given at any organization. Insecure wireless configuration can provide an easy open door for
malicious threat actors.
2. Purpose
The purpose of this policy is to secure and protect the information assets owned by <Company
Name>. <Company Name> provides computer devices, networks, and other electronic information
systems to meet missions, goals, and initiatives.
30 | P a g e
<Company Name> grants access to these resources as a privilege and must manage them
responsibly to maintain the confidentiality, integrity, and availability of all information assets.
This policy specifies the conditions that wireless infrastructure devices must satisfy to connect to
<Company Name> network. Only those wireless infrastructure devices that meet the standards
specified in this policy or are granted an exception by the Information Security Department are
approved for connectivity to a <Company Name> network.
3. Scope
All employees, contractors, consultants, temporary and other workers at <Company Name>,
including all personnel affiliated with third parties that maintain a wireless infrastructure device on
behalf of <Company Name> must adhere to this policy. This policy applies to all wireless
infrastructure devices that connect to a <Company Name> network or reside on a <Company Name>
site that provide wireless connectivity to endpoint devices including, but not limited to, laptops,
desktops, cellular phones, and tablets. This includes any form of wireless communication device
capable of transmitting packet data.
4. Policy
4.1 General Requirements
All wireless infrastructure devices that reside at a <Company Name> site and connect to a <Company
Name> network, or provide access to information classified as <Company Name> Confidential, or
above must:
 Abide by the standards specified in the Wireless Communication Standard.
 Be installed, supported, and maintained by an approved support team.
 Use <Company Name> approved authentication protocols and infrastructure.
 Use <Company Name> approved encryption protocols.
 Maintain a hardware address (MAC address) that can be registered and tracked.
 Not interfere with wireless access deployments maintained by other support organizations.
4.2 Lab and Isolated Wireless Device Requirements
All lab wireless infrastructure devices that provide access to <Company Name> Confidential or
above, must adhere to section 4.1 above. Lab and isolated wireless devices that do not provide
general network connectivity to the <Company Name> network must:
 Be isolated from the corporate network (that is it must not provide any corporate
connectivity) and comply with the Lab Security Policy.
 Not interfere with wireless access deployments maintained by other support organizations.
4.3 Home Wireless Device Requirements
4.3.1 Wireless infrastructure devices that provide direct access to the <Company Name>
corporate network, must conform to the Home Wireless Device Requirements as detailed in
the Wireless Communication Standard.
31 | P a g e
4.3.2
Wireless infrastructure devices that fail to conform to the Home Wireless Device
Requirements must be installed in a manner that prohibits direct access to the <Company
Name> corporate network. Access to the <Company Name> corporate network through this
device must use standard remote access authentication.
5. Policy Compliance
8.1 Compliance Measurement
The Infosec team will verify compliance to this policy through various methods, including but not
limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits,
and feedback to the policy owner.
8.2 Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
8.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.
9
Related Standards, Policies and Processes
 Lab Security Policy
 Wireless Communication Standard
10 Definitions and Terms
The following definition and terms can be found in the SANS Glossary located at:
https://www.sans.org/security-resources/glossary-of-terms/

MAC Address
11 Revision History
Date of Change
Responsible
Summary of Change
Server Security Policy
1. Overview
Unsecured and vulnerable servers continue to be a major entry point for malicious threat actors.
Consistent Server installation policies, ownership and configuration management are all about doing
the basics well.
32 | P a g e
2. Purpose
The purpose of this policy is to establish standards for the base configuration of internal server
equipment that is owned and/or operated by <Company Name>. Effective implementation of this
policy will minimize unauthorized access to <Company Name> proprietary information and
technology.
3. Scope
All employees, contractors, consultants, temporary and other workers at Cisco and its subsidiaries
must adhere to this policy. This policy applies to server equipment that is owned, operated, or
leased by Cisco or registered under a Cisco-owned internal network domain.
This policy specifies requirements for equipment on the internal Cisco network. For secure
configuration of equipment external to Cisco on the DMZ, see the Internet DMZ Equipment Policy.
4. Policy
4.1 General Requirements
4.1.1 All internal servers deployed at <Company Name> must be owned by an operational group
that is responsible for system administration. Approved server configuration guides must be
established and maintained by each operational group, based on business needs and
approved by InfoSec. Operational groups should monitor configuration compliance and
implement an exception policy tailored to their environment. Each operational group must
establish a process for changing the configuration guides, which includes review and
approval by InfoSec. The following items must be met:
 Servers must be registered within the corporate enterprise management system. At a
minimum, the following information is required to positively identify the point of
contact:
o Server contact(s) and location, and a backup contact
o Hardware and Operating System/Version
o Main functions and applications, if applicable
 Information in the corporate enterprise management system must be kept up-to-date.
 Configuration changes for production servers must follow the appropriate change
management procedures
4.1.2 For security, compliance, and maintenance purposes, authorized personnel may monitor
and audit equipment, systems, processes, and network traffic per the Audit Policy.
4.2 Configuration Requirements
4.2.1 Operating System configuration should be in accordance with approved InfoSec guidelines.
4.2.2 Services and applications that will not be used must be disabled where practical.
4.2.3 Access to services should be logged and/or protected through access-control methods such
as a web application firewall, if possible.
33 | P a g e
4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
The most recent security patches must be installed on the system as soon as practical, the
only exception being when immediate application would interfere with business
requirements.
Trust relationships between systems are a security risk, and their use should be avoided. Do
not use a trust relationship when some other method of communication is sufficient.
Always use standard security principles of least required access to perform a function. Do
not use root when a non-privileged account will do.
If a methodology for secure channel connection is available (i.e., technically feasible),
privileged access must be performed over secure channels, (e.g., encrypted network
connections using SSH or IPSec).
Servers should be physically located in an access-controlled environment.
Servers are specifically prohibited from operating from uncontrolled cubicle areas.
4.3 Monitoring
4.3.1 All security-related events on critical or sensitive systems must be logged and audit trails
saved as follows:
 All security related logs will be kept online for a minimum of 1 week.
 Daily incremental tape backups will be retained for at least 1 month.
 Weekly full tape backups of logs will be retained for at least 1 month.
 Monthly full backups will be retained for a minimum of 2 years.
4.3.2 Security-related events will be reported to InfoSec, who will review logs and report incidents
to IT management. Corrective measures will be prescribed as needed. Security-related
events include, but are not limited to:
 Port-scan attacks
 Evidence of unauthorized access to privileged accounts
 Anomalous occurrences that are not related to specific applications on the host.
5. Policy Compliance
11.1 Compliance Measurement
The Infosec team will verify compliance to this policy through various methods, including but not
limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits,
and feedback to the policy owner.
11.2 Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
11.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.
6
Related Standards, Policies and Processes
 Audit Policy
 DMZ Equipment Policy
7 Definitions and Terms
The following definition and terms can be found in the SANS Glossary located at:
34 | P a g e
https://www.sans.org/security-resources/glossary-of-terms/

8
De-militarized zone (DMZ)
Revision History
Date of Change
Responsible
Summary of Change
Information Logging Standard
1. Overview
Logging from critical systems, applications and services can provide key information and potential
indicators of compromise. Although logging information may not be viewed on a daily basis, it is
critical to have from a forensics standpoint.
2. Purpose
The purpose of this document attempts to address this issue by identifying specific requirements
that information systems must meet in order to generate appropriate audit logs and integrate with
an enterprise’s log management function.
The intention is that this language can easily be adapted for use in enterprise IT security policies and
standards, and also in enterprise procurement standards and RFP templates. In this way,
organizations can ensure that new IT systems, whether developed in-house or procured, support
necessary audit logging and log management functions.
3. Scope
This policy applies to all production systems on <Company Name> Network.
4. Standard
4.1 General Requirements
All systems that handle confidential information, accept network connections, or make access
control (authentication and authorization) decisions shall record and retain audit-logging
information sufficient to answer the following questions:
1. What activity was performed?
2. Who or what performed the activity, including where or on what system the activity was
performed from (subject)?
3. What the activity was performed on (object)?
35 | P a g e
4. When was the activity performed?
5. What tool(s) was the activity was performed with?
6. What was the status (such as success vs. failure), outcome, or result of the activity?
7.
4.2 Activities to be Logged
Therefore, logs shall be created whenever any of the following activities are requested to be
performed by the system:
1. Create, read, update, or delete confidential information, including confidential
authentication information such as passwords;
2. Create, update, or delete information not covered in #1;
3. Initiate a network connection;
4. Accept a network connection;
5. User authentication and authorization for activities covered in #1 or #2 such as user login
and logout;
6. Grant, modify, or revoke access rights, including adding a new user or group, changing user
privilege levels, changing file permissions, changing database object permissions, changing
firewall rules, and user password changes;
7. System, network, or services configuration changes, including installation of software
patches and updates, or other installed software changes;
8. Application process startup, shutdown, or restart;
9. Application process abort, failure, or abnormal end, especially due to resource exhaustion or
reaching a resource limit or threshold (such as for CPU, memory, network connections,
network bandwidth, disk space, or other resources), the failure of network services such as
DHCP or DNS, or hardware fault; and
10. Detection of suspicious/malicious activity such as from an Intrusion Detection or Prevention
System (IDS/IPS), anti-virus system, or anti-spyware system.
4.3 Elements of the Log
Such logs shall identify or contain at least the following elements, directly or indirectly. In this
context, the term “indirectly” means unambiguously inferred.
1. Type of action – examples include authorize, create, read, update, delete, and accept
network connection.
2. Subsystem performing the action – examples include process or transaction name, process
or transaction identifier.
3. Identifiers (as many as available) for the subject requesting the action – examples include
user name, computer name, IP address, and MAC address. Note that such identifiers should
be standardized in order to facilitate log correlation.
36 | P a g e
4. Identifiers (as many as available) for the object the action was performed on – examples
include file names accessed, unique identifiers of records accessed in a database, query
parameters used to determine records accessed in a database, computer name, IP address,
and MAC address. Note that such identifiers should be standardized in order to facilitate log
correlation.
5. Before and after values when action involves updating a data element, if feasible.
6. Date and time the action was performed, including relevant time-zone information if not in
Coordinated Universal Time.
7. Whether the action was allowed or denied by access-control mechanisms.
8. Description and/or reason-codes of why the action was denied by the access-control
mechanism, if applicable.
4.4 Formatting and Storage
The system shall support the formatting and storage of audit logs in such a way as to ensure the
integrity of the logs and to support enterprise-level analysis and reporting. Note that the
construction of an actual enterprise-level log management mechanism is outside the scope of this
document. Mechanisms known to support these goals include but are not limited to the following:
1. Microsoft Windows Event Logs collected by a centralized log management system;
2. Logs in a well-documented format sent via syslog, syslog-ng, or syslog-reliable network
protocols to a centralized log management system;
3. Logs stored in an ANSI-SQL database that itself generates audit logs in compliance with the
requirements of this document; and
4. Other open logging mechanisms supporting the above requirements including those based
on CheckPoint OpSec, ArcSight CEF, and IDMEF.
5. Policy Compliance
11.4 Compliance Measurement
The Infosec team will verify compliance to this policy through various methods, including but not
limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits,
and feedback to the policy owner.
11.5 Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
11.6 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.
6
7
Related Standards, Policies and Processes
None.
Definitions and Terms
None.
37 | P a g e
8
Revision History
Date of Change
Responsible
Summary of Change
By putting in place corporate policies and processes to develop secure baseline builds and manage
the configuration and the ongoing functionality of all Information and Communications Technologies
(ICT), organisations can greatly improve the security of their ICT systems. Good corporate practice is
to develop a strategy to remove or disable unnecessary functionality from ICT systems and keep
them patched against known vulnerabilities. Failure to do so is likely to result in increased exposure
of the business and its ICT to threats and vulnerabilities and therefore increased risk to the
confidentiality, integrity and availability of systems and information7.
Identify security requirements for the ICT system or application
What is the risk?
Establishing and then actively maintaining the secure configuration of ICT systems should be seen as
a key security control. ICT systems that are not locked down, hardened or patched will be
particularly vulnerable to attacks that may be easily prevented.
Organisations that fail to produce and implement corporate security policies that manage the secure
configuration and patching of their ICT systems are subject to the following risks:
Unauthorised changes to systems
An attacker could make unauthorised changes to ICT systems or information, compromising
confidentiality, availability and integrity
Exploitation of unpatched vulnerabilities
New patches are released almost daily and the timely application of security patches is critical to
preserving the confidentiality, integrity and availability of ICT systems.
7
Source: UK Government, as at https://www.gov.uk/government/publications/10-steps-to-cyber-securityadvice-sheets/10-steps-secure-configuration--11, as on 9th May, 2017.
38 | P a g e
Attackers will attempt to exploit unpatched systems to provide them with unauthorised access to
system resources and information. Many successful attacks are enabled by exploiting a vulnerability
for which a patch had been issued prior to the attack taking place
Exploitation of insecure system configurations
An attacker could exploit a system that has not been locked down or hardened by:




Gaining unauthorised access to information assets or importing malware
Exploiting unnecessary functionality that has not been removed or disabled to conduct
attacks and gain unauthorised access to systems, services, resources and information
Connecting unauthorised equipment to exfiltrate information or introduce malware
Creating a back door to use in the future for malicious purposes
Increases in the number of security incidents
Without an awareness of vulnerabilities that have been identified and the availability (or not) of
patches and fixes, the business will be increasingly disrupted by security incidents
Risk management is an increasingly important element of corporate governance and is closely
associated with the pursuit of improved business performance, innovation and productivity. The
identification, analysis, acceptance and mitigation of risk is essential to the process of buying and
implementing new IT products8.
By identifying potential risks in advance of undertaking a business activity or business decision,
management can determine the likelihood and potential impact of the risks identified, as well as
strategies to avert or minimise the threats that each risk poses.
Many companies may already have a standing Risk Committee, comprising employees, managers
and/or board members, as appropriate. Typically, such a committee would be chaired by the
operations manager, a senior executive or a board member, and would regularly meet to review and
assess a company’s risk exposures and risk treatment activities.
General Risk Management Methodologies
Two useful methodologies for managing risks are the ‘Risk Register’ and the ‘Risk Matrix’. The Risk
Register is a list of all risks that have been identified, their significance (i.e. whether the risk is likely
and how severe its impact will be if it occurs) and whether there is a way of mitigating (reducing)
the impact.
The headings in a typical Risk Register look something like this:
8
Source: Australian Government, Business, as at https://www.business.gov.au/.../Innovation-Connectionsquick-guide-managing-ICT-r..., as on 9th May, 2017.
39 | P a g e
Risk
Number
e.g. R01
Risk
Description
Corruption
of customer
data
Likelihood
of
Occurring
(Lo/Med/
Hi)
Med
Impact if it
Occurs
(Lo/Med/
Hi)
Agreed Risk
Mitigation
Treatment
Residual
Risk Rating
(Lo/Med/Hi
)
Risk Owner
Hi
Full back up
Lo
Sales
of customer
Manager to
records,
sign off
always
before
reconcile
going live.
before new
Often a company will maintain a general risk register for all system
of its activities
and periodically report to
gosenior managers and board members on the status of theselive.
risks. If a company is undertaking a new
initiative or project, it will typically create a risk register specifically focused on this new initiative.
The important discipline with the risk register is that there is a designated person who is responsible
for maintaining it and that there is a regular risk review process during which all active risks are
reviewed, to ensure that all risks are being monitored and treated.
The Risk Matrix is a visual tool that is very useful for highlighting the key risks confronting any project
or business. There are a variety of sophisticated visual presentations, but all employ the same basic
concepts. For a small and medium business, the following type of presentation will often be
sufficient:
Risk Matrix – Residual Risks Following Risk Treatment
Business
Impact if
Risk Occurs
High
R06 *
R12
Medium
R02, R09
R10, R11
R08
Low
R01, R04, R13, R14, R03, R05, R07
R15, R16, R17, R18,
R19, R120, R21, R22,
R23
Low
High
Medium
Likelihood of Risk Occurring
Legend:
Low Risk
Medium Risk
High Risk
* The codes R01, R02 etc. above refer to risk numbers in the relevant Risk Register
When using risk management methodologies as illustrated above, it is important to ensure the status
40 | P a g e
of risks is regularly monitored by management and that all risks in the Medium to High (orange to
red coloured) categories are managed intensively to minimise the business risk they pose if risk
mitigation action is not taken.
For a more in depth explanation of the broader discipline of risk management, refer
to the Australian Standard AS/NZS ISO 31000:2009 Risk Management – Principles and
Guidelines.
ICT Risks
ICT risks are an increasingly important part of corporate risk management, because
they include such threats as business interruption, disaster recovery, business and
information security, data back-up and protection, software licence compliance, ICT
outsourcing and cloud services, and employee and contractor internet and social
media use. However, one of the most important and far-reaching areas of ICT risk
relates to how new or improved IT products are evaluated, purchased and
implemented within a business. This is because new or changed IT systems can have
game-changing impacts on a business, potentially affecting many areas.
If well thought through, these changes can be extremely positive, creating major
business improvements. But careful planning and project management are required,
otherwise a new IT system can have major, negative impacts; extending well beyond
employees, to customers and suppliers and, ultimately, the viability of the business
itself.
The Major Types of IT Risk for Business
In recent years, a variety of industry surveys of IT risk for business have been conducted across many
firms in many industries in a large number of countries. From these types of survey, it is possible to
identify four Common themes of IT risks for businesses:
1. Risks caused by falling behind
Firms failing to leverage readily available technology to improve business performance, access to
markets and competitive position, with the result that they lose ground against competitors and
new market entrants.
2. Risks caused by buying without sufficient care:
Firms making IT choices that do not fit with their other IT systems (or those of key customers or
suppliers), that do not produce the benefits expected and take much longer to implement, or which
create unexpected new costs.
3. Risks caused by failing to establish and maintain organisational commitment:
41 | P a g e
Firms failing to ensure adequate preparatory training and buy-in by staff, not ensuring strong
project alignment and commitment from senior management, and failing to ensure project
timelines and new system cut-overs occur as planned. All of which can lead to projects failing to
realise anticipated benefits and where legacy systems often continue to run in parallel.
4. Risks caused by missing the opportunity to innovate:
Firms not being sufficiently strategic in their IT choices. This is perhaps the greatest risk and can be
a consequence of any of the three foregoing risks. Because the opportunity costs of failing to
maximise the potential transformative effects of new IT products and solutions can stifle innovation
and best-in-class performance.
All businesses need to be constantly alert to the potential transformative effects of IT and to
adopt systematic processes for evaluating, selecting, buying and implementing IT in just the same
way that they would approach any other major, long-term business decision.
Identifying and Managing Risks during the IT Product/Service Assessment Stage
You should start by asking the following four questions:
1. Do we have a clear idea of our requirements?
2. How have others solved this requirement and what problems have they
encountered?
3. Has our initial market research identified solutions with the potential to meet our
requirements?
4. Do we have enough information to compare the costs and benefits of potential
solutions?
One of the best start-points in establishing a sound risk management approach towards IT projects is
to review the problem that you are trying to solve or the requirements that you have identified.
Often you will need to visit trade shows, conduct internet searches of available solutions and make
enquiries of vendors and other businesses with which you interact or of industry associations of
which you are a member.
The objective is to gain as much understanding of what is available in the market- place and how
closely these offerings match your particular requirements.
For some businesses, these initial enquiries may be undertaken by one of the owners themselves, in
the first instance, or this may be a project that can be allocated to a suitable member of the
management team.
Either way, it is important, that this early process also involves consultation within the business –
especially those whose work area will potentially be affected. Obtaining input to requirements and
ensuring the regular review of preliminary findings is a key element in ensuring alignment and buy-in,
as well as ensuring that important considerations are not overlooked.
42 | P a g e
Depending on the size of the business and the extent of the ICT solution under evaluation, a project
team may need to be constituted and specialised external expertise may need to be bought in to
augment the process.
Once this early ‘scoping’ phase of your potential IT purchase is complete it is important, as part of
the process of establishing the ‘business case’, to analyse the findings and the risks that have been
identified.
Tips:
Try listing out potential risks under the following headings:
Requirement Risks: e.g. are the requirements documented and agreed by internal stakeholders?
Technology Risks: e.g. have the options available and relevant IT trends been adequately
researched/validated?
Project Management Risks: e.g. is there sufficient capacity to finance and manage the
kind of changes envisaged?
Project Scheduling Risks: e.g. are there any internal or external factors that impact on when the IT
solution can be implemented, and will the changes need to occur in stages?
Project Governance Risks: e.g. Are there clear arrangements in place governing accountability for
consultation, sign offs and decision-making?
Identifying and Managing Risks during the Procurement Phase
Once a business has taken a decision to proceed beyond evaluating possible solutions, the serious
commitments (and potential risks) commence. It is therefore important to have a clear idea about
how ICT procurement works and how to minimise the commercial and business risks involved.
ICT procurement typically involves four components:

Hardware (such as a computer server or other equipment);

Software (such as a new customer relationship management system or accounting
system);

Implementation services (such as the setting to work of the new hardware, the
setting up of the new software, migration of existing data to the new system and
staff training); and

Ongoing support.
Some ICT procurements will involve only one of these categories, but for most ICT
procurements all four elements need to be considered collectively. A common
procurement risk occurs when a business attempts to purchase these components
separately and inadvertently become responsible for system integration.
43 | P a g e
Larger businesses will have one or more existing ICT personnel, who can advise on some
aspects of procurement, but they will also be busy managing existing IT activities and may not
have the time or expertise to manage a significant ICT procurement process.
An important first step is therefore determining whether a business has the in-house capacity to
manage ICT procurement, or whether specialist assistance will be required. If specialist assistance is
required, the business should consult with their other advisors (such as their accountants and/or
lawyers) as well as their industry association, before making a decision on who to engage.
If using an external advisor, ask for references from other clients who had similar needs and make
sure you check with those clients about their experience, before making an appointment. In terms of
the risks and risk mitigation strategies that a business should consider when commencing the
procurement phase, the following issues are very common potential problems that can be averted if
care is taken at the outset.
It is important to avoid committing to a single vendor until all of these questions can be answered:
General Procurement Risks
E.g. how will you decide on a vendor – will you seek quotations? Will you provide
vendors with a briefing and an information package? Do you have a draft contract?
Have you considered how you will structure payments to ensure that you have
control over the vendor’s performance? Will you use your legal or accounting firm
to assist with managing elements of the procurement process? What process will you
follow to determine a preferred vendor?
Vendor-related Risks
E.g. Before selecting a preferred vendor, have you checked whether the short-listed vendors have
a reputation for successfully meeting requirements similar to yours? Have you spoken with (and
even visited) some of the short-listed vendors’ reference sites? Do the vendors have the capacity to
be on site and/or respond to calls for assistance when you need them at your location(s)?
Are you sure that you understand the structure of each short-listed vendor’s pricing and
ongoing support terms. (For example, some vendors will require you to pay an annual software
licence fee and if you fail to do so, the software will be deactivated and some cloud service
providers may not allow you to transfer your data if you change vendors.)
Do each of the short-listed vendors have a detailed implementation schedule and have you
walked through it with them to make sure that you agree with their approach and that you can
meet any obligations that you have to provide resources, etc.?
Have you ensured that the key internal stakeholders have had an opportunity to understand and
agree to the preferred vendor’s proposal and to meet the vendor and visit or speak to reference
sites, if appropriate?
Have you conducted a web search on the short-listed vendors to determine if there are any
customer complaints posted on discussion boards and so forth?
44 | P a g e
System Compatibility Risks
This is a potentially major risk that often only emerges after the procurement decision has been
taken. A very good way to avoid this is to have the preferred vendor conduct a small on-site trial
to demonstrate how the new system will interface with other business systems.
E.g. will the new system interface neatly with all your existing business systems or will there be a
need to upgrade or modify those systems so that they can ‘talk’ to the new system.
Use this process to identify whether any changes need to be made to network configuration (such as
to support more users or to handle multi-site connections), or to adjust on or off-site data storage,
back-up or disaster recovery arrangements.
Also use this opportunity to assess the adequacy of business change management plans, such as
training needed for users of the new system, opportunities to streamline business processes and
retire legacy systems.
This is also a good way to ensure that the vendor fully understands the requirements of the project.
It is important that such a trial is undertaken before any final purchase commitment is given. This
will generally ensure that the vendor undertakes the pilot at no charge or for a nominal fee and it
provides the business with a valuable opportunity for a pre-purchase reality check.
During the past two or three years an increasing range of so-called cloud services has become
available. These services are particularly suited to many businesses needs since they essentially
outsource many of the traditional hardware and software procurement and maintenance
activities to a specialist vendor. For example, many businesses no longer have in-house
accounting systems, customer management systems, email systems, switchboards, call centres,
secretarial services, and so forth. In the age of the internet, these are all services that can be
purchased on a subscription basis and accessed from any location.
In considering IT procurement options, it is becoming increasingly important to also
consider whether a cloud service offers a viable alternative to an outright purchase.
Identifying and Managing Risks during the Implementation Phase
If a business conducts its evaluation and procurement phases well, the system
implementation phase will be relatively straight-forward. Conversely, deficiencies in
evaluation and procurement will surface during implementation and when this does
occur, the results can be very painful for all involved.
A successful implementation is based on thorough planning, so it is important to
ensure that the staff and the vendor have a well-prepared plan at the commencement
of the implementation phase.
This ‘Implementation Plan’ is often one of the first deliverables for a vendor and can be used as a
trigger for their first milestone payment. Important implementation challenges that should be
addressed in the implementation plan include:

Determining the system testing and acceptance regime -
E.g. how will the vendor demonstrate that the system is correctly performing to requirements,
before it goes live?
45 | P a g e

Depending on the scale of the ICT project, this may entail the initial establishment
of a test bed or test environment (on site or at the vendor’s premises), so that the
new system can be configured and tested without disruption to business as usual
activities.

Determining how much configuration of the new system should be undertaken -
E.g. If an business is upgrading its accounting system, will it bring across its existing chart of accounts,
or adopt a new account structure that is designed to make better use of the new system’s in-built
reporting functionality?

Planning how (and when) data from existing systems will be migrated to the new
system -
E.g. Will all of a firm’s customer and vendor data be transferred into the new system, or
only customers and vendors from, say, the past two years? If only some data is to be
transferred, how will the other data be accessed if required?
Tips:
An ICT system Implementation Plan should determine:

The system testing and acceptance regime

How much configuration of the new system should be undertaken

Planning how and when data from existing systems will be migrated to the new
system

System security requirements

Training requirements for affected staff

Board and senior management issues

Go-live and Cut-over arrangements

Transitioning to ‘Business as Usual’ and Benefits Realisation

System Security requirements -
E.g. Ensuring that any new hardware required is installed (either on site or in a hosted
environment) and that associated network and data security operates as required.

Training for Affected Personnel -
E.g. How much training is required, can it be accommodated ‘on the job’ or will staff
need to be released for training sessions? How will business disruption be minimised?
46 | P a g e
Are staff prepared to undertake
disruption?

additional hours of work/training to minimise
Board and Senior Management Issues -
E.g. Are the board and senior management involved in monitoring the project and
committed to its implementation? Will there be any impact on the reporting and control
processes that they are used to, are they aware of these changes?

Go-live and Cut-over Arrangements -
E.g. Determining how the business will cut-over to the new system – will it be over a
weekend (with sufficient time to roll-back to the old system if there is a problem)? Will
there be a staged go-live process, possibly starting at only one site initially and then
expanding once the system is known to be working? Will certain key customers or
vendors be advised in advance so that any important processing can be completed
before the cut-over commences. Will vendor personnel be required on- site during cutover to help with any trouble-shooting?

Transitioning to ‘Business as Usual’ and Benefits Realisation -
E.g. what is the warranty period for rectification of bugs and deficiencies? How much of the
contract value is held back pending final acceptance? Has all training and documentation been
delivered? What on-going support arrangements are in place?
Often a major ICT investment is partly based on the realisation of savings, such as
reduced running costs of legacy systems, productivity improvements or reduced
inventories. It is important to press for the realisation of these benefits and to
measure the relevant aspects of business performance before and after.
Risk Management is designed to enable Businesses to Grow, Innovate and Pursue Opportunities
ICT is now one of the major drivers of global productivity and innovation.
Businesses need to invest in IT and leverage its game-changing potential. This is
particularly the case for small and medium sized businesses, which make up well over
90% of all Australian businesses.
Successful businesses have systems and management approaches that are designed to do a better
job of managing risk than their competitors. The purpose of this guide to managing risks when
buying or implementing new IT systems is to help businesses better understand IT risks, so that
they can better manage them.
47 | P a g e
How can the risk be managed?
Develop corporate policies to update and patch systems
Use the latest versions of operating systems, web browsers and applications. Develop and
implement corporate policies to ensure that security patches are applied in a timeframe that is
commensurate with the organisation’s overall risk management approach. Organisations should use
automated patch management and software update tools.
Create and maintain hardware and software inventories
Create inventories of the authorised hardware and software that constitute ICT systems across the
organisation. Ideally, suitably configured automated tools should be used to capture the physical
location, the business owner and the purpose of the hardware together with the version and
patching status of all software used on the system. The tools should also be used to identify any
unauthorised hardware or software, which should be removed.
Lock down operating systems and software
Consider the balance between system usability and security and then document and implement a
secure baseline build for all ICT systems, covering clients, mobile devices, servers, operating systems,
applications and network devices such as firewalls and routers. Essentially, any services,
functionality or applications that are not required to support the business should be removed or
disabled. The secure build profile should be managed by the configuration control and management
process and any deviation from the standard build should be documented and formally approved.
Conduct regular vulnerability scans
Organisations should run automated vulnerability scanning tools against all networked devices
regularly and remedy any identified vulnerabilities within an agreed time frame. Organisations
should also maintain their situational awareness of the threats and vulnerabilities they face.
Establish configuration control and management
Produce policies and procedures that define and support the configuration control and change
management requirements for all ICT systems, including software.
Disable unnecessary input/output devices and removable media access
Assess business requirements for user access to input/output devices and removable media (this
could include MP3 players and Smart phones). Disable ports and system functionality that is not
needed by the business (which may include USB ports, CD/DVD/Card media drives)
Implement whitelisting and execution control
48 | P a g e
Create and maintain a whitelist of authorised applications and software that can be executed on ICT
systems. In addition, ICT systems need to be capable of preventing the installation and execution of
unauthorised software and applications by employing process execution controls, software
application arbiters and only accepting code that is signed by trusted suppliers;
Limit user ability to change configuration
Provide users with the minimum system rights and permissions that they need to fulfil their business
role. Users with ‘normal’ privileges should be prevented from installing or disabling any software or
services running on the system.
Activity 2
How can ICT security risk evaluation inform an organisation’s security requirements?
49 | P a g e
Activity 2
50 | P a g e
How to write an information security policy9
An information security policy is the cornerstone of an information security program. It should
reflect the organization's objectives for security and the agreed upon management strategy for
securing information.
In order to be useful in providing authority to execute the remainder of the information security
program, it must also be formally agreed upon by executive management. This means that, in order
to compose an information security policy document, an organization has to have well-defined
objectives for security and an agreed-upon management strategy for securing information. If there is
debate over the content of the policy, then the debate will continue throughout subsequent
attempts to enforce it, with the consequence that the information security program itself will be
dysfunctional.
What to do first
There is a plethora of security-policy-in-a-box products on the market, but few of them will be
formally agreed upon by executive management without being explained in detail by a security
professional. This is not likely to happen due to time constraints inherent in executive management.
Even if it was possible to immediately have management endorse an off-the-shelf policy, it is not the
right approach to attempt to teach management how to think about security. Rather, the first step
in composing a security policy is to find out how management views security. As a security policy is,
by definition, a set of management mandates with respect to information security, these mandates
provide the marching orders for the security professional. If the security professional instead
provides mandates to executive management to sign off on, management requirements are likely to
be overlooked.
If there is debate over the content of the policy, then the debate will continue throughout
subsequent attempts to enforce it, with the consequence that the information security program
itself will be dysfunctional.
A security professional whose job it is to compose security policy must therefore assume the role of
sponge and scribe for executive management. A sponge is a good listener who is able to easily
absorb the content of each person's conversation regardless of the group's diversity with respect to
communication skills and culture. A scribe documents that content faithfully without embellishment
or annotation. A good sponge and scribe will be able to capture common themes from management
interviews and prepare a positive statement about how the organization as a whole wants its
information protected. The time and effort spent to gain executive consensus on policy will pay off
in the authority it lends to the policy enforcement process.
Good interview questions that solicit management's opinions on information security are:
9
Source: CSO, as at http://www.csoonline.com/article/2124114/it-strategy/strategic-planning-erm-how-towrite-an-information-security-policy.html, as on 9th May, 2017.
51 | P a g e



How would you describe the different types of information you work with?
Which types of information do you rely on to make decisions?
Are there any information types that are more of a concern to keep private than others?
From these questions, an information classification system can be developed (e.g., customer info,
financial info, marketing info, etc), and appropriate handling procedures for each can be described at
the business process level.
Of course, a seasoned security professional will also have advice on how to mold the management
opinion with respect to security into a comprehensive organizational strategy. Once it is clear that
the security professional completely understands management's opinions, it should be possible to
introduce a security framework that is consistent with it. The framework will be the foundation of
the organization's Information Security Program, and thus will service as a guide for creating an
outline of the information security policy.
Creating a framework
Often, a security industry standards document is used as the baseline framework. For example, the
Security Forum's Standard of Good Practice (www.securityforum.org), the International Standards
Organization's Security Management series (27001, 27002, 27005, www.iso.org), and the
Information Systems Audit and Control Association's Control Objectives for Information Technology
(CoBIT, www.isaca.org). This is a reasonable approach, as it helps to ensure that the policy will be
accepted as adequate not only by company management, but also by external auditors and others
who may have a stake in the organization's Information Security Program.
However, these documents are inherently generic and do not state specific management objectives
for security. So they must be combined with management input to produce the policy outline.
Moreover, it is not reasonable to expect the management of an organization to change the way the
organization is managed in order to comply with a standards document. Rather, the information
security professional may learn about good security management practices from these documents,
and see if it is possible to incorporate them into the current structure of the target organization.
Make it about mandates
It is important that security policy always reflect actual practice. Otherwise, the moment the policy is
published, the organization is not compliant. It is better to keep policy as a very small set of
mandates to which everyone agrees and can comply than to have a very far-reaching policy that few
in the organization observe. The information security program can then function to enforce policy
compliance while the controversial issues are simultaneously addressed.
... where people are aware that there are no exceptions to policy, they will generally be more willing
to assist in getting it right up front
Another reason that it is better to keep policy as a very small set of mandates to which everyone
agrees is that, where people are aware that there are no exceptions to policy, they will generally be
more willing to assist in getting it right up front to ensure that they will be able to comply going
forward.
52 | P a g e
Once a phrase such as "exceptions to this policy may be made by contacting the executive in charge
of...." slips into the policy itself or the program in which it is used, the document becomes
completely meaningless. It no longer represents management commitment to an information
security program, but instead communicates suspicion that the policy will not be workable.
A security professional should consider that if such language were to make its way into a human
resources or accounting policy, people could thus be excused from sexual harassment or expense
report fraud. A security professional should strive to ensure that information security policy is
observed at the same level as other policies enforced within the organization. Policy language should
be crafted in such a way that guarantees complete consensus among executive management.
For example, suppose there is debate about whether users should have access to removable media
such as USB storage devices. A security professional may believe that such access should never be
required while a technology executive may believe that technology operations departments
responsible for data manipulation must have the ability to move data around on any type of media.
At the policy level, the consensus-driven approach would produce a general statement that "all
access to removable media devices is approved via a process supported by an accountable
executive." The details of the approval processes used by the technology executive can be further
negotiated as discussions continue. The general policy statement still prohibits anyone without an
accountable executive supporting an approval process from using removable media devices.
Employing sub-policies
In very large organizations, details on policy compliance alternatives may differ considerably. In
these cases, it may be appropriate to segregate policies by intended audience. The organizationwide policy then becomes a global policy, including only the least common denominator of security
mandates. Different sub-organizations may then publish their own policies. Such distributed policies
are most effective where the audience of sub-policy documents is a well-defined subset of the
organization. In this case, the same high level of management commitment need not be sought in
order to update these documents.
For example, information technology operations policy should require only information technology
department head approval as long as it is consistent with the global security policy, and only
increases the management commitment to consistent security strategy overall. It would presumably
include such directives as "only authorized administrators should be provided access capable of
implementing operating system configuration changes" and "passwords for generic IDs should be
accessed only in the context of authorized change control processes." Another type of sub-policy may
involve people in different departments engaged in some unusual activity that is nevertheless
subject to similar security controls, such as outsourcing information processing, or encrypting email
communications.
The time and effort spent to gain executive consensus on policy will pay off in the authority it lends
to the policy enforcement process.
On the other hand, subject-specific policies that apply to all users should not be cause to draft new
policies, but should be added as sections in the global policy.
53 | P a g e
Multiple policies containing organization-wide mandates should be discouraged because multiple
policy sources make it more difficult to accomplish a consistent level of security awareness for the
any given individual user. It is hard enough to establish policy-awareness programs that reach all in
the intended community, without having to clarify why multiple policy documents were created
when one would do. For example, new organization-wide restrictions on internet access need not be
cause to create a new "internet access" policy. Rather, an "internet access" section can be added to
the global security policy.
Another caveat for the security professional using the sub-policy approach is to make sure subpolicies do not repeat what is in the global policy, and at the same time are consistent with it.
Repetition must be prohibited as it would allow policy documents to get out of sync as they
individually evolve. Rather, the sub-documents should refer back to the global document and the
two documents should be linked in a manner convenient for the reader.
Supplementary documents
Even while giving sub-policies due respect, wherever there is an information security directive that
can be interpreted in multiple ways without jeopardizing the organization's commitment to
information security goals, a security professional should hesitate to include it in any policy. Policy
should be reserved for mandates. Alternative implementation strategies can be stated as a
responsibility, standard, process, procedure, or guideline. This allows for innovation and flexibility at
the department level while still maintaining firm security objectives at the policy level.
This does not mean that the associated information protection goals should be removed from the
information security program. It just means that not all security strategy can be documented at the
policy level of executive mandate. As the information security program matures, the policy can be
updated, but policy updates should not be necessary to gain incremental improvements in security.
Additional consensus may be continuously improved using other types of Information Security
Program documents.
Supplementary documents to consider are:
Roles and responsibilities — Descriptions of security responsibilities executed by departments other
than the security group. For example, technology development departments may be tasked with
testing for security vulnerabilities prior to deploying code and human resources departments may be
tasked with keeping accurate lists of current employees and contractors.
Technology standards — Descriptions of technical configuration parameters and associated values
that have been determined to ensure that management can control access to electronic information
assets.
Process - Workflows demonstrating how security functions performed by different departments
combine to ensure secure information-handling.
Procedures — Step by step instructions for untrained staff to perform routine security tasks in ways
that ensure that the associated preventive, detective, and/or response mechanisms work as
planned.
54 | P a g e
Guidelines — Advice on the easiest way to comply with security policy, usually written for nontechnical users who have multiple options for secure information-handling processes.
What an information security policy includes
This leaves the question: what is the minimum information required to be included in an information
security policy? It must be at least enough to communicate management aims and direction with
respect to security. It should include:
1. Scope — should address all information, systems, facilities, programs, data, networks and all
users of technology in the organization, without exception
2. Information classification — should provide content-specific definitions rather than generic
"confidential" or "restricted"
3. Management goals — goals for secure handling of information in each classification
category (e.g., legal, regulatory, and contractual obligations for security) may be combined
and phrased as generic objectives such as "customer privacy entails no authorized cleartext
access to customer data for anyone but customer representatives and only for purposes of
communicating with customer," "information integrity entails no write access outside
accountable job functions," and "prevent loss of assets"
4. Context — Placement of the policy in the context of other management directives and
supplementary documents (e.g., is agreed by all at executive level, all other information
handling documents must be consistent with it)
5. Supporting documents — include references to supporting documents (e.g., roles and
responsibilities, process, technology standards, procedures, guidelines)
6. Specific instructions — include instruction on well-established organization-wide security
mandates (e.g., all access to any computer system requires identity verification and
authentication, no sharing of individual authentication mechanisms)
7. Responsibilities — outline specific designation of well-established responsibilities (e.g., the
technology department is the sole provider of telecommunications lines)
8. Consequences — include consequences for non-compliance (e.g., up to and including
dismissal or termination of contract)
This list of items will suffice for information security policy completeness with respect to current
industry best practice as long as accountability for prescribing specific security measures is
established within the "supplementary documents" and "responsibilities" section. While items 6 and
7 may contain a large variety of other agreed-upon details with respect to security measures, it is ok
to keep them to a minimum to maintain policy readability and rely on sub-policies or supporting
documents to include the requirements. Again, it is more important to have complete compliance at
the policy level than to have the policy include a lot of detail.
Note that the policy production process itself is something that necessarily exists outside of the
policy document. Documentation with respect to policy approvals, updates and version control
should also be carefully preserved and available in the event that the policy production process is
audited.
55 | P a g e
Security in the software development life cycle10
Small changes in the software development life cycle can substantially improve security without
breaking the bank or the project schedule.
The software development life cycle, or SDLC, encompasses all of the steps that an organization
follows when it develops software tools or applications. Organizations that incorporate security in
the SDLC benefit from products and applications that are secure by design. Those that fail to involve
information security in the life cycle pay the price in the form of costly and disruptive events.
In an organization that's been around for several years or more, the SDLC is well-documented and
usually includes the steps that are followed and in what order, the business functions and/or
individuals responsible for carrying out the steps and information about where records are kept.
10
Source: Tech Target, as at http://searchsecurity.techtarget.com/tip/Security-in-the-software-developmentlife-cycle, as on 9th May, 2017.
56 | P a g e
A typical SDLC model contains the following main functions:







Conceptual definition. This is a basic description of the new product or program being
developed, so that anyone reading it can understand the proposed project.
Functional requirements and specifications. This is a list of requirements and specifications
from a business function perspective.
Technical requirements and specifications. This is a detailed description of technical
requirements and specifications in technical terms.
Design. This is where the formal detailed design of the product or program is developed.
Coding. The actual development of software.
Test. This is the formal testing phase.
Implementation. This is where the software or product is installed in production.
Each major function consists of several tasks, perhaps documented in flowchart notation
with inputs, outputs, reports, decisions and approvals. Some companies build workflow
applications to support all of this.
Getting the right security information to the right people
Many people in the entire development process need all kinds of information, including
security information, in a form that is useful to them. Here is the type of information that is
required during each phase of the SDLC.







Conceptual -- Organization information security principles and strategies
Functional requirements and specifications -- Information security requirements
Technical requirements and specifications -- Information security requirements
Design -- Enterprise security architecture and security product standards
Coding -- Development standards, practices, libraries and coding examples
Testing -- Test plans that show how to verify each security requirement
Implementation -- Procedures for integrating existing authentication, access controls,
encryption, backup, etc.
If you are wondering why maintenance is omitted from the life cycle example here, it is
because maintenance is just an iteration of the life cycle: when a change is needed, the
entire process starts all over again. All of the validations that are present the first time
through the life cycle are needed every time thereafter.
Finally, one may say that these changes represent a lot of extra work in a development
project. This is not the case – these additions do not present that much extra time. These are
but small additions that reap large benefits later on.
Approval: Moving to the next step
Organizations that use a software development life cycle process usually have approval
steps at each major function. This takes the form of some kind of an approval meeting with
the right stakeholders present: generally you find managers, directors, occasionally a VP –
the people who control budgets, resources and business priorities.
57 | P a g e
Someone who represents information security should be present and have the authority to
vote at most, if not all, major steps in the life cycle. If someone representing infosec is not
present at a life cycle approval meeting, then there is a risk that a project lacking some key
security component will be approved, only to become a problem in the future.
Fix it now or pay the price later
Organizations that fail to involve information security in the life cycle will pay the price in the
form of costly and disruptive events. Many bad things can happen to information systems
that lack the required security interfaces and characteristics. Some examples include:



Orphan user accounts (still-active accounts that belong to employees or contractors who
have left the organization) that exist because the information system does not integrate
with an organization's identity management or single sign-on solution.
Defaced Web sites as a result of systems that were not built to security standards and,
therefore, include easily exploited weaknesses.
Fraudulent transactions that occur because an application lacked adequate audit trails
and/or the processes required to ensure they are examined and issues dealt with.
You should figure that problems like these are all costly to solve – in most cases far more
costly than the little bit of extra effort required to build the products or applications
correctly in the first place.
Write an ICT system or application security plan according to the enterprise
and ICT system or application security policies
All companies should develop and maintain clear and robust policies for safeguarding critical
business data and sensitive information, protecting their reputation and discouraging inappropriate
behaviour by employees11.
Many of these types of policies already exist for “real world” situations, but may need to be tailored
to your organization and updated to reflect the increasing impact of cyberspace on everyday
transactions, both professional and personal. As with any other business document, cyber security
policies should follow good design and governance practices -- not so long that they become
unusable, not so vague that they become meaningless, and reviewed on a regular basis to ensure
that they stay pertinent as your business needs change.
Please note that this document does not address all policy requirements for businesses that fall
under legislative acts or directives, such as the Health Insurance Portability and Accountability Act,
Sarbanes-Oxley Act or other federal, state or local statutes.
11
Source: Federal Communications Commission, US, as at
https://www.dhs.gov/sites/default/files/publications/FCC%20Cybersecurity%20Planning%20Guide_1.pdf, as
on 9th May, 2017.
58 | P a g e
Cyber Plan Action Items:
1. Establish security roles and responsibilities
One of the most effective and least expensive means of preventing serious cyber security incidents is
to establish a policy that clearly defines the separation of roles and responsibilities with regard to
systems and the information they contain. Many systems are designed to provide for strong RoleBased Access Control (RBAC), but this tool is of little use without well-defined procedures and
policies to govern the assignment of roles and their associated constraints. Such policies need to
clearly state, at a minimum:
• Clearly identify company data ownership and employee roles for security oversight and their
inherit privileges, including: o Necessary roles, and the privileges and constraints accorded to those
roles. o The types of employees who should be allowed to assume the various roles. o How long an
employee may hold a role before access rights must be reviewed. o If employees may hold multiple
roles, the circumstances defining when to adopt one role over another.
Depending on the types of data regularly handled by your business, it may also make sense to create
separate policies governing who is responsible for certain types of data. For example, a business that
handles large volumes of personally identifiable information (PII) from its customers may benefit
from identifying a chief steward for customers’ privacy information. The steward could serve not
only as a subject matter expert on all matters of privacy, but also to serve as the champion for
process and technical improvements to PII handling.
2. Establish an employee Internet usage policy
The limits on employee Internet usage in the workplace vary widely from business to business. Your
guidelines should allow employees the maximum degree of freedom they require to be productive
(short breaks to surf the web or perform personal tasks online have been shown to increase
productivity). At the same time, rules of behaviour are necessary to ensure that all employees are
aware of boundaries, both to keep them safe and to keep your company successful. Some to
consider:
• Personal breaks to surf the web should be limited to a reasonable amount of time and to certain
types of activities.
• If you use a web filtering system, employees should have clear knowledge of how and why their
web activities will be monitored, and what types of sites are deemed unacceptable by your policy.
• Workplace rules of behaviour should be clear, concise and easy to follow. Employees should feel
comfortable performing both personal and professional tasks online without making judgment calls
as to what may or may not be deemed appropriate. Businesses may want to include a splash
warning upon network sign-on that advises the employees of the businesses’ Internet usage policies
so that all employees are on notice.
59 | P a g e
3. Establish a social media policy
Social networking applications present a number of risks that are difficult to address using technical
or procedural solutions. A strong social media policy is crucial for any business that seeks to use
social networking to promote its activities and communicate with its customers. At a minimum, a
social media policy should clearly include the following:
• Specific guidance on when to disclose company activities using social media, and what kinds of
details can be discussed in a public forum.
• Additional rules of behavior for employees using personal social networking accounts to make
clear what kinds of discussion topics or posts could cause risk for the company.
• Guidance on the acceptability of using a company email address to register for, or get notices
from, social media sites.
• Guidance on selecting long and strong passwords for social networking accounts, since very few
social media sites enforce strong authentication policies for users.
Lastly, all users of social media need to be aware of the risks associated with social networking tools
and the types of data that can be automatically disclosed online when using social media. Taking the
time to educate your employees on the potential pitfalls of social media use, especially in tandem
with geo-location services, may be the most beneficial social networking security practice of all.
4. Identify potential reputation risks
All organizations should take the time to identify potential risks to their reputation and develop a
strategy to mitigate those risks via policies or other measures as available. Specific types of
reputation risks include:
• Being impersonated online by a criminal organization (e.g., an illegitimate website spoofing your
business name and copying your site design, then attempting to defraud potential customers via
phishing scams or other method).
• Having sensitive company or customer information leaked to the public via the web. • Having
sensitive or inappropriate employee actions made public via the web or social media sites.
All businesses should set a policy for managing these types of risks and plans to address such
incidents if and when they occur. Such a policy should cover a regular process for identifying
potential risks to the company’s reputation in cyberspace, practical measures to prevent those risks
from materializing and reference plans to respond and recover from potential incidents as soon as
they occur.
60 | P a g e
Scams and Fraud
New telecommunication technologies may offer countless opportunities for small businesses, but
they also offer cyber criminals many new ways to victimize your business, scam your customers and
hurt your reputation. Businesses of all sizes should be aware of the most common scams
perpetrated online.
Cyber Plan Action Items:
1. Train employees to recognize social engineering
Social engineering, also known as "pretexting," is used by many criminals, both online and off, to
trick unsuspecting people into giving away their personal information and/or installing malicious
software onto their computers, devices or networks. Social engineering is successful because the
bad guys are doing their best to make their work look and sound legitimate, sometimes even helpful,
which makes it easier to deceive users.
Most offline social engineering occurs over the telephone, but it frequently occurs online, as well.
Information gathered from social networks or posted on websites can be enough to create a
convincing ruse to trick your employees. For example, LinkedIn profiles, Facebook posts and Twitter
messages can allow a criminal to assemble detailed dossiers on employees. Teaching people the
risks involved in sharing personal or business details on the Internet can help you partner with your
staff to prevent both personal and organizational losses.
Many criminals use social engineering tactics to get individuals to voluntarily install malicious
computer software such as fake antivirus, thinking they are doing something that will help make
them more secure.
Users who are
tricked into loading malicious programs on their computers may be providing remote control
capabilities to an attacker, unwittingly installing software that can steal financial information or
simply try to sell them fake security software.
2. Protect against online fraud
Online fraud takes on many guises that can impact everyone, including small businesses and their
employees. It is helpful to maintain consistent and predictable online messaging when
communicating with your customers to prevent others from impersonating your company.
Be sure to never request personal information or account details through email, social networking or
other online messages. Let your customers know you will never request this kind of information
through such channels and instruct them to contact you directly should they have any concerns.
61 | P a g e
3. Protect against phishing
Phishing is the technique used by online criminals to trick people into thinking they are dealing with
a trusted website or other entity. Small businesses face this threat from two directions -- phishers
may be impersonating them to take advantage of unsuspecting customers, and phishers may be
trying to steal their employees’ online credentials.
Businesses should ensure that their online communications never ask their customers to submit
sensitive information via email. Make a clear statement in your communications reinforcing that you
will never ask for personal information via email so that if someone targets your customers, they
may realize the request is a scam.
Employee awareness is your best defense against your users being tricked into handing over their
usernames and passwords to cyber criminals. Explain to everyone that they should never respond to
incoming messages requesting private information. Also, to avoid being led to a fake site, they
should know to never click on a link sent by email from an untrustworthy source. Employees needing
to access a website link sent from a questionable source should open an Internet browser window
and manually type in the site’s web address to make sure the emailed link is not maliciously
redirecting to a dangerous site.
This advice is especially critical for protecting online banking accounts belonging to your
organization. Criminals are targeting small business banking accounts more than any other sector.
4. Don’t fall for fake antivirus offers
Fake antivirus, "scareware" and other rogue online security scams have been behind some of the
most successful online frauds in recent times. Make sure your organization has a policy in place
explaining what the procedure is if an employee's computer becomes infected by a virus.
Train your employees to recognize a legitimate warning message (using a test file from eicar.org, for
example) and to properly notify your IT team if something bad or questionable has happened. If
possible, configure your computers to not allow regular users to have administrative access. This will
minimize the risk of them installing malicious software and condition users that adding unauthorized
software to work computers is against policy.
5. Protect against malware
Businesses can experience a compromise through the introduction of malicious software, or
malware, that tracks a user’s keyboard strokes, also known as key logging.
Many businesses are falling victim to key-logging malware being installed on computer systems in
their environment. Once installed, the malware can record keystrokes made on a computer, allowing
bad guys to see passwords, credit card numbers and other confidential data. Keeping security
software up to date and patching your computers regularly will make it more difficult for this type of
malware to infiltrate your network.
62 | P a g e
6. Develop a layered approach to guard against malicious software
Despite progress in creating more awareness of security threats on the Internet, malware authors
are not giving up. The malware research firm SophosLabs reports seeing more than 100,000 unique
malicious software samples every single day.
Effective protection against viruses, Trojans and other malicious software requires a layered
approach to your defenses. Antivirus software is a must, but should not be a company’s only line of
defense. Instead, deploy a combination of many techniques to keep your environment safe.
Also, be careful with the use of thumb drives and other removable media. These media could have
malicious software pre-installed that can infect your computer, so make sure you trust the source of
the removable media devices before you use them.
Combining the use of web filtering, antivirus signature protection, proactive malware protection,
firewalls, strong security policies and employee training significantly lowers the risk of infection.
Keeping protection software up to date along with your operating system and applications increases
the safety of your systems.
7. Verify the identity of telephone information seekers
Most offline social engineering occurs over the telephone. Information gathered through social
networks and information posted on websites can be enough to create a convincing ruse to trick
your employees. Ensure that you train employees to never disclose customer information,
usernames, passwords or other sensitive details to incoming callers. When someone requests
information, always contact the person back using a known phone number or email account to verify
the identity and validity of the individual and their request.
Network Security
Securing your company’s network consists of: (1) identifying all devices and connections on the
network; (2) setting boundaries between your company’s systems and others; and (3) enforcing
controls to ensure that unauthorized access, misuse, or denial-of-service events can be thwarted or
rapidly contained and recovered from if they do occur.
Cyber Plan Action Items:
1. Secure internal network and cloud services
Your company’s network should be separated from the public Internet by strong user authentication
mechanisms and policy enforcement systems such as firewalls and web filtering proxies. Additional
monitoring and security solutions, such as anti-virus software and intrusion detection systems,
should also be employed to identify and stop malicious code or unauthorized access attempts.
Internal network
63 | P a g e
After identifying the boundary points on your company’s network, each boundary should be
evaluated to determine what types of security controls are necessary and how they can be best
deployed. Border routers should be configured to only route traffic to and from your company’s
public IP addresses, firewalls should be deployed to restrict traffic only to and from the minimum set
of necessary services, and intrusion prevention systems should be configured to monitor for
suspicious activity crossing your network perimeter. In order to prevent bottlenecks, all security
systems you deploy to your company’s network perimeter should be capable of handling the
bandwidth that your carrier provides.
Cloud based services
Carefully consult your terms of service with all cloud service providers to ensure that your
company’s information and activities are protected with the same degree of security you would
intend to provide on your own. Request security and auditing from your cloud service providers as
applicable to your company’s needs and concerns. Review and understand service level agreements,
or SLAs, for system restoration and reconstitution time.
You should also inquire about additional services a cloud service can provide. These services may
include backupand-restore services and encryption services, which may be very attractive to small
businesses.
2. Develop strong password policies
Generally speaking, two-factor authentication methods, which require two types of evidence that
you are who you claim to be, are safer than using just static passwords for authentication. One
common example is a personal security token that displays changing passcodes to be used in
conjunction with an established password. However, two-factor systems may not always be possible
or practical for your company.
Password policies should encourage your employees to employ the strongest passwords possible
without creating the need or temptation to reuse passwords or write them down. That means
passwords that are random, complex and long (at least 10 characters), that are changed regularly,
and that are closely guarded by those who know them.
3. Secure and encrypt your company’s Wi-Fi Wireless access control
Your company may choose to operate a Wireless Local Area Network (WLAN) for the use of
customers, guests and visitors. If so, it is important that such a WLAN be kept separate from the
main company network so that traffic from the public network cannot traverse the company’s
internal systems at any point.
Internal, non-public WLAN access should be restricted to specific devices and specific users to the
greatest extent possible while meeting your company’s business needs.
64 | P a g e
Where the internal WLAN has less stringent access controls than your company’s wired network,
dual connections -- where a device is able to connect to both the wireless and wired networks
simultaneously -- should be prohibited by technical controls on each such capable device (e.g., BIOSlevel LAN/WLAN switch settings). All users should be given unique credentials with preset expiration
dates to use when accessing the internal WLAN.
Wireless encryption
Due to demonstrable security flaws known to exist in older forms of wireless encryption, your
company’s internal WLAN should only employ Wi-Fi Protected Access 2 (WPA2) encryption.
4. Encrypt sensitive company data
Encryption should be employed to protect any data that your company considers sensitive, in
addition to meeting applicable regulatory requirements on information safeguarding. Different
encryption schemes are appropriate under different circumstances. However, applications that
comply with the OpenPGP standard, such as PGP and GnuPG, provide a wide range of options for
securing data on disk as well as in transit. If you choose to offer secure transactions via your
company’s website, consult with your service provider about available options for an SSL certificate
for your site.
5. Regularly update all applications
All systems and software, including networking equipment, should be updated in a timely fashion as
patches and firmware upgrades become available. Use automatic updating services whenever
possible, especially for security systems such as anti-malware applications, web filtering tools and
intrusion prevention systems.
6. Set safe web browsing rules
Your company’s internal network should only be able to access those services and resources on the
Internet that are essential to the business and the needs of your employees. Use the safe browsing
features included with modern web browsing software and a web proxy to ensure that malicious or
unauthorized sites cannot be accessed from your internal network.
7. If remote access is enabled, make sure it is secure
If your company needs to provide remote access to your company’s internal network over the
Internet, one popular and secure option is to employ a secure Virtual Private Network (VPN) system
accompanied by strong two-factor authentication, using either hardware or software tokens.
Website Security
Website security is more important than ever.
65 | P a g e
Web servers, which host the data and other content available to your customers on the Internet, are
often the most targeted and attacked components of a company’s network. Cyber criminals are
constantly looking for improperly secured websites to attack, while many customers say website
security is a top consideration when they choose to shop online. As a result, it is essential to secure
servers and the network infrastructure that supports them. The consequences of a security breach
are great: loss of revenues, damage to credibility, legal liability and loss of customer trust.
The following are examples of specific security threats to web servers:
• Cyber criminals may exploit software bugs in the web server, underlying operating system, or
active content to gain unauthorized access to the web server. Examples of unauthorized access
include gaining access to files or folders that were not meant to be publicly accessible and being able
to execute commands and/or install malicious software on the web server.
• Denial-of-service attacks may be directed at the web server or its supporting network
infrastructure to prevent or hinder your website users from making use of its services.
• Sensitive information on the web server may be read or modified without authorization.
• Sensitive information on backend databases that are used to support interactive elements of a
web application may be compromised through the injection of unauthorized software commands.
Examples include Structured Query Language (SQL) injection, Lightweight Directory Access Protocol
(LDAP) injection and cross-site scripting (XSS).
• Sensitive unencrypted information transmitted between the web server and the browser may be
intercepted.
• Information on the web server may be changed for malicious purposes. Website defacement is a
commonly reported example of this threat.
• Cyber criminals may gain unauthorized access to resources elsewhere in the organization’s
network via a successful attack on the web server.
• Cyber criminals may also attack external entities after compromising a web server. These attacks
can be launched directly (e.g., from the compromised server against an external server) or indirectly
(e.g., placing malicious content on the compromised web server that attempts to exploit
vulnerabilities in the web browsers of users visiting the site).
• The server may be used as a distribution point for attack tools, pornography or illegally copied
software. Cyber Plan Action Items:
1. Carefully plan and address the security aspects of the deployment of a public web server.
Because it is much more difficult to address security once deployment and implementation have
occurred, security should be considered from the initial planning stage.
66 | P a g e
Businesses are more likely to make decisions about configuring computers appropriately and
consistently when they develop and use a detailed, well-designed deployment plan. Developing such
a plan will support web server administrators in making the inevitable tradeoff decisions between
usability, performance and risk.
Businesses also need to consider the human resource requirements for the deployment and
continued operation of the web server and supporting infrastructure. The following points in a
deployment plan:
• Types of personnel required -- for example, system and web server administrators, webmasters,
network administrators and information systems security personnel.
• Skills and training required by assigned personnel.
• Individual (i.e., the level of effort required of specific personnel types) and collective staffing (i.e.,
overall level of effort) requirements.
2. Implement appropriate security management practices and controls when maintaining and
operating a secure web server.
Appropriate management practices are essential to operating and maintaining a secure web server.
Security practices include the identification of your company’s information system assets and the
development, documentation and implementation of policies, and guidelines to help ensure the
confidentiality, integrity and availability of information system resources. The following practices
and controls are recommended:
• A business-wide information system security policy.
• Server configuration and change control and management.
• Risk assessment and management.
• Standardized software configurations that satisfy the information system security policy.
• Security awareness and training.
• Contingency planning, continuity of operations and disaster recovery planning.
• Certification and accreditation.
3. Ensure that web server operating systems meet your organization’s security requirements.
The first step in securing a web server is securing the underlying operating system. Most commonly
available web servers operate on a general-purpose operating system. Many security issues can be
avoided if the operating systems underlying web servers are configured appropriately.
67 | P a g e
Default hardware and software configurations are typically set by manufacturers to emphasize
features, functions and ease of use at the expense of security. Because manufacturers are not aware
of each organization’s security needs, each web server administrator must configure new servers to
reflect their business’ security requirements and reconfigure them as those requirements change.
Using security configuration guides or checklists can assist administrators in securing systems
consistently and efficiently. Initially securing an operating system initially generally includes the
following steps:
• Patch and upgrade the operating system.
• Change all default passwords
• Remove or disable unnecessary services and applications.
• Configure operating system user authentication.
• Configure resource controls.
• Install and configure additional security controls.
• Perform security testing of the operating system.
4. Ensure the web server application meets your organization’s security requirements.
In many respects, the secure installation and configuration of the web server application will mirror
the operating system process discussed above. The overarching principle is to install the minimal
amount of web server services required and eliminate any known vulnerabilities through patches or
upgrades. If the installation program installs any unnecessary applications, services or scripts, they
should be removed immediately after the installation process concludes. Securing the web server
application generally includes the following steps:
• Patch and upgrade the web server application.
• Remove or disable unnecessary services, applications and sample content.
• Configure web server user authentication and access controls.
• Configure web server resource controls.
• Test the security of the web server application and web content.
5. Ensure that only appropriate content is published on your website.
Company websites are often one of the first places cyber criminals search for valuable information.
Still, many businesses lack a web publishing process or policy that determines what type of
information to publish openly, what information to publish with restricted access and what
information should not be published to any publicly accessible repository. Some generally accepted
68 | P a g e
examples of what should not be published or at least should be carefully examined and reviewed
before being published on a public website include:
• Classified or proprietary business information.
• Sensitive information relating to your business’ security.
• Medical records.
• A business’ detailed physical and information security safeguards.
• Details about a business’ network and information system infrastructure -- for example, address
ranges, naming conventions and access numbers.
• Information that specifies or implies physical security vulnerabilities.
• Detailed plans, maps, diagrams, aerial photographs and architectural drawings of business
buildings, properties or installations.
• Any sensitive information about individuals that might be subject to federal, state or, in some
instances, international privacy laws.
6. Ensure appropriate steps are taken to protect web content from unauthorized access or
modification.
Although information available on public websites is intended to be public (assuming a credible
review process and policy is in place), it is still important to ensure that information cannot be
modified without authorization. Users of such information rely on its integrity even if the
information is not confidential. Content on publicly accessible web servers is inherently more
vulnerable than information that is inaccessible from the Internet, and this vulnerability means
businesses need to protect public web content through the appropriate configuration of web server
resource controls. Examples of resource control practices include:
• Install or enable only necessary services.
• Install web content on a dedicated hard drive or logical partition.
• Limit uploads to directories that are not readable by the web server.
• Define a single directory for all external scripts or programs executed as part of web content.
• Disable the use of hard or symbolic links.
• Define a complete web content access matrix identifying which folders and files in the web server
document directory are restricted, which are accessible, and by whom.
• Disable directory listings.
69 | P a g e
• Deploy user authentication to identify approved users, digital signatures and other cryptographic
mechanisms as appropriate.
• Use intrusion detection systems, intrusion prevention systems and file integrity checkers to spot
intrusions and verify web content.
• Protect each backend server (i.e., database server or directory server) from command injection
attacks.
7. Use active content judiciously after balancing the benefits and risks.
Static information resided on the servers of most early websites, typically in the form of text-based
documents. Soon thereafter, interactive elements were introduced to offer new opportunities for
user interaction.
Unfortunately, these same interactive elements introduced new web-related vulnerabilities. They
typically involve dynamically executing code using a large number of inputs, from web page URL
parameters to hypertext transfer protocol (HTTP) content and, more recently, extensible markup
language (XML) content. Different active content technologies pose different related vulnerabilities,
and their risks should be weighed against their benefits. Although most websites use some form of
active content generators, many also deliver some or all of their content in a static form.
8. Use authentication and cryptographic technologies as appropriate to protect certain types of
sensitive data.
Public web servers often support technologies for identifying and authenticating users with differing
privileges for accessing information. Some of these technologies are based on cryptographic
functions that can provide a secure channel between a web browser client and a web server that
supports encryption. Web servers may be configured to use different cryptographic algorithms,
providing varying levels of security and performance.
Without proper user authentication in place, businesses cannot selectively restrict access to specific
information. All information that resides on a public web server is then accessible by anyone with
access to the server. In addition, without some process to authenticate the server, users of the
public web server will not be able to determine whether the server is the “authentic” web server or
a counterfeit version operated by a cyber-criminal.
Even with an encrypted channel and an authentication mechanism, it is possible that attackers may
attempt to access the site by brute force. Improper authentication techniques can allow attackers to
gather valid usernames or potentially gain access to the website. Strong authentication mechanisms
can also protect against phishing attacks, in which hackers may trick users into providing their
personal credentials, and pharming, in which traffic to a legitimate website may be redirected to an
illegitimate one. An appropriate level of authentication should be implemented based on the
sensitivity of the web server’s users and content.
70 | P a g e
9. Employ network infrastructure to help protect public web servers.
The network infrastructure (e.g., firewalls, routers, intrusion detection systems) that supports the
web server plays a critical security role. In most configurations, the network infrastructure will be
the first line of defense between a public web server and the Internet. Network design alone,
though, cannot protect a web server. The frequency, sophistication and variety of web server attacks
perpetrated today support the idea that web server security must be implemented through layered
and diverse protection mechanisms, an approach sometimes referred to as “defense-indepth.”
10. Commit to an ongoing process of maintaining web server security.
Maintaining a secure web server requires constant effort, resources and vigilance. Securely
administering a web server on a daily basis is essential. Maintaining the security of a web server will
usually involve the following steps:
• Configuring, protecting and analyzing log files.
• Backing up critical information frequently.
• Maintaining a protected authoritative copy of your organization’s web content.
• Establishing and following procedures for recovering from compromise.
• Testing and applying patches in a timely manner.
• Testing security periodically.
Email
Email has become a critical part of our everyday business, from internal management to direct
customer support. The benefits associated with email as a primary business tool far outweigh the
negatives. However, businesses must be mindful that a successful email platform starts with basic
principles of email security to ensure the privacy and protection of customer and business
information.
Cyber Plan Action Items:
1. Set up a spam email filter
It has been well documented that spam, phishing attempts and otherwise unsolicited and
unwelcome email often accounts for more than 60 percent of all email that an individual or business
receives. Email is the primary method for spreading viruses and malware and it is one of the easiest
to defend against. Consider using email-filtering services that your email service, hosting provider or
other cloud providers offer.
71 | P a g e
A local email filter application is also an important component of a solid antivirus strategy. Ensure
that automatic updates are enabled on your email application, email filter and anti-virus programs.
Ensure that filters are reviewed regularly so that important email and/or domains are not blocked in
error.
2. Train your employees in responsible email usage
The last line of defense for all of your cyber risk efforts lies with the employees who use tools such
as email and their responsible and appropriate use and management of the information under their
control. Technology alone cannot make a business secure. Employees must be trained to identify
risks associated with email use, how and when to use email appropriate to their work, and when to
seek assistance of professionals. Employee awareness training is available in many forms, including
printed media, videos and online training.
Consider requiring security awareness training for all new employees and refresher courses every
year. Simple efforts such as monthly newsletters, urgent bulletins when new viruses are detected,
and even posters in common areas to remind your employees of key security and privacy to-do’s
create a work environment that is educated in protecting your business.
3. Protect sensitive information sent via email
With its proliferation as a primary tool to communicate internally and externally, business email
often includes sensitive information. Whether it is company information that could harm your
business or regulated data such as personal health information (PHI) or personally identifiable
information (PII), it is important to ensure that such information is only sent and accessed by those
who are entitled to see it.
Since email in its native form is not designed to be secure, incidents of misaddressing or other
common accidental forwarding can lead to data leakage. Businesses that handle this type of
information should consider whether such information should be sent via email, or at least consider
using email encryption. Encryption is the process of converting data into unreadable format to
prevent disclosure to unauthorized personnel. Only individuals or organizations with access to the
encryption key can read the information. Other cloud services offer “Secure Web Enabled Drop
Boxes” that enable secure data transfer for sensitive information, which is often a better approach
to transmitting between companies or customers.
4. Set a sensible email retention policy
Another important consideration is the management of email that resides on company messaging
systems and your users’ computers. From the cost of storage and backup to legal and regulatory
requirements, companies should document how they will handle email retention and implement
basic controls to help them attain those standards.
72 | P a g e
Many industries have specific rules that dictate how long emails can or should be retained, but the
basic rule of thumb is only as long as it supports your business efforts. Many companies implement a
60-90 day retention standard if not compelled by law to another retention period.
To ensure compliance, companies should consider mandatory archiving at a chosen retention cycle
end date and automatic permanent email removal after another set point, such as180-360 days in
archives. In addition, organizations should discourage the use of personal folders on employee
computers (most often configurable from the e-mail system level), as this will make it more difficult
to manage company standards.
5. Develop an email usage policy
Policies are important for setting expectations with your employees or users, and for developing
standards to ensure adherence to your published polices.
Your policies should be easy to read, understand, define and enforce. Key areas to address include
what the company email system should and should not be used for, and what data are allowed to be
transmitted. Other policy areas should address retention, privacy and acceptable use.
Depending on your business and jurisdiction, you may have a need for email monitoring. The rights
of the business and the user should be documented in the policy as well. The policy should be part of
your general end user awareness training and reviewed for updates on a yearly basis.
Mobile Devices
If your company uses mobile devices to conduct company business, such as accessing company
email or sensitive data, pay close attention to mobile security and the potential threats that can
expose and compromise your overall business networks. This section describes the mobile threat
environment and the practices that small businesses can use to help secure devices such as
smartphones, tablets and Wi-Fi enabled laptops.
Many organizations are finding that employees are most productive when using mobile devices, and
the benefits are too great to ignore. But while mobility can increase workplace productivity, allowing
employees to bring their own mobile devices into the enterprise can create significant security and
management challenges.
Data loss and data breaches caused by lost or stolen phones create big challenges, as mobile devices
are now used to store confidential business information and access the corporate network.
According to a December 2010 Symantec mobile security survey, 68 percent of respondents ranked
loss or theft as their top mobile-device security concern, while 56 percent said mobile malware is
their number two concern. It is important to remember that while the individual employee may be
liable for a device, the company is still liable for the data.
Top threats targeting mobile devices
73 | P a g e
• Data Loss – An employee or hacker accesses sensitive information from device or network. This
can be unintentional or malicious, and is considered the biggest threat to mobile devices
• Social Engineering Attacks – A cybercriminal attempts to trick users to disclose sensitive
information or install malware. Methods include phishing and targeted attacks.
• Malware – Malicious software that includes traditional computer viruses, computer worms and
Trojan horse programs. Specific examples include the Ikee worm, targeting iOS-based devices; and
Pjapps malware that can enroll infected Android devices in a collection of hacker-controlled
“zombie” devices known as a “botnet.”
• Data Integrity Threats – Attempts to corrupt or modify data in order to disrupt operations of a
business for financial gain. These can also occur unintentionally.
• Resource Abuse – Attempts to misuse network, device or identity resources. Examples include
sending spam from compromised devices or denial of service attacks using computing resources of
compromised devices.
• Web and Network-based Attacks – Launched by malicious websites or compromised legitimate
sites, these target a device’s browser and attempt to install malware or steal confidential data that
flows through it.
Cyber Plan Action Items:
A few simple steps can to help ensure company information is protected. These include requiring all
mobile devices that connect to the business network be equipped with security software and
password protection; and providing general security training to make employees aware of the
importance of security practices for mobile devices. More specific practices are detailed below.
1. Use security software on all smartphones
Security software specifically designed for smartphones can stop hackers and prevent cyber
criminals from stealing your information or spying on you when you use public networks.
threats before they cause you problems. It can also eliminate annoying text and multimedia spam
messages. It can detect and remove viruses and other mobile
2. Make sure all software is up to date
Mobile devices must be treated like personal computers in that all software on the devices should
be kept current, especially the security software. This will protect devices from new variants of
malware and viruses that threaten your company’s critical information.
3. Encrypt the data on mobile devices
74 | P a g e
Business and personal information stored on mobile devices is often sensitive. Encrypting this data is
another must. If a device is lost and the SIM card stolen, the thief will not be able to access the data
if the proper encryption technology is loaded on the device.
4. Have users password protect access to mobile devices
In addition to encryption and security updates, it is important to use strong passwords to protect
data stored on mobile devices. This will go a long way toward keeping a thief from accessing
sensitive data if the device is lost or hacked.
5. Urge users to be aware of their surroundings
Whether entering passwords or viewing sensitive or confidential data, users should be cautious of
who might be looking over their shoulder.
6. Employ these strategies for email, texting and social networking
Avoid opening unexpected text messages from unknown senders – As with email, attackers can use
text messages to spread malware, phishing scams and other threats among mobile device users. The
same caution should be applied to opening unsolicited text messages that users have become
accustomed to with email.
Don’t be lured in by spammers and phishers – To shield business networks from cyber criminals,
small businesses should deploy appropriate email security solutions, including spam prevention,
which protect a company’s reputation and manage risks.
Click with caution – Just like on stationary PCs, social networking on mobile devices and laptops
should be conducted with care and caution. Users should not open unidentified links, chat with
unknown people or visit unfamiliar sites. it.
7. Set reporting procedures for lost or stolen equipment
In the case of a loss or theft, employees and management should all know what to do next.
Processes to deactivate the device and protect its information from intrusion should be in place.
Products are also available for the automation of such processes, allowing small businesses to
breathe easier after such incidents.
8. Ensure all devices are wiped clean prior to disposal
Most mobile devices have a reset function that allows all data to be wiped. SIM cards should also be
removed and destroyed.
It doesn’t take much for a user to be tricked into compromising a device and the information on
75 | P a g e
Employees
Businesses must establish formal recruitment and employment processes to control and preserve
the quality of their employees. Many employers have learned the hard way that hiring someone
with a criminal record, falsified credentials or undesirable background can create a legal and
financial nightmare.
Without exercising due diligence in hiring, employers run the risk of making unwise hiring choices
that can lead to workplace violence, theft, embezzlement, lawsuits for negligent hiring and
numerous other workplace problems.
Cyber Plan Action Items:
1. Develop a hiring process that properly vets candidates
The hiring process should be a collaborative effort among different groups of your organization,
including recruitment, human resources, security, legal and management teams.
It is important to have a solid application,
resume, interview and reference-checking process to identify potential gaps and issues that may
appear in a background check.
An online employment screening resource called the “Online Safe Hiring Certification Course” can
help you set the groundwork for a safe recruitment process. The course will teach your teams what
to look for in the different stages of the hiring process, how to interview and how to set up a safe
hiring program to avoid hiring an employee that may be problematic. The course is available here:
http://www.esrcheck.com/ESRonlineSafeHiringCourse.php.
2. Perform background checks and credentialing
76 | P a g e
Background checks are essential and must be consistent. Using a background screening company is
highly recommended. The standard background screening should include the following checks:
• Employment verification
• Education verification
• Criminal records
• Drug testing
• The U.S. Treasury Office of Foreign Affairs and Control
• Sex offender registries
• Social Security traces and validation
Depending on the type of your business, other screening criteria may consist of credit check, civil
checks and federal criminal checks. Conducting post-hire checks for all employees every two to three
years, depending on your industry, is also recommended.
If you do conduct background checks, you as an employer have obligations under the Fair Credit
Reporting Act. For more information about employer obligations under the FCRA, visit
http://business.ftc.gov/documents/bus08using-consumer-reports-what-employers-need-know.
3. Take care in dealing with third parties
Employers should properly vet partner companies through which your organization hires third-party
consultants. To ensure consistent screening criteria are enforced for third-party consultants, you
need to explicitly set the credentialing requirements in your service
4. Set appropriate access controls for employees
Both client data and internal company data are considered confidential and need particular care
when viewed, stored, used, transmitted or disposed.
It is important to analyze the role of each employee and set data access control
based upon the role. If a role does not require the employee to ever use sensitive data, the
employee’s access to the data should be strictly prohibited. However, if the role requires the
employee to work with sensitive data, the level of access must be analyzed thoroughly and be
assigned in a controlled and tiered manner following “least-privilege” principles, which allow the
employee to only access data that is necessary to perform his or her job.
If the organization does not have a system in place to control data access, the following precautions
are strongly recommended. Every employee should:
77 | P a g e
• Never access or view client data without a valid business reason. Access should be on a need-toknow basis.
• Never provide confidential data to anyone – client representatives, business partners or even
other employees – unless you are sure of the identity and authority of that person.
• Never use client data for development, testing, training presentations or any purpose other than
providing production service, client-specific testing or production diagnostics. Only properly
sanitized data that cannot be traced to a client, client employee, customer or your organization’s
employee should be used for such purposes.
• Always use secure transmission methods such as secure email, secure file transfer (from
application to application) and encrypted electronic media (e.g., CDs, USB drives or tapes).
• Always keep confidential data (hard copy and electronic) only as long as it is needed. • Follow a
“clean desk” policy, keeping workspaces uncluttered and securing sensitive documents so that
confidential information does not get into the wrong hands.
• Always use only approved document disposal services or shred all hardcopy documents containing
confidential information when finished using them. Similarly, use only approved methods that fully
remove all data when disposing of, sending out for repair or preparing to reuse electronic media.
5. Provide security training for employees
Security awareness training teaches employees to understand system vulnerabilities and threats to
business operations that are present when using a computer on a business network.
A strong IT security program must include training IT users on security policy, procedures and
techniques, as well as the various management, operational and technical controls necessary and
available to keep IT resources secure. In addition, IT infrastructure managers must have the skills
necessary to carry out their assigned duties effectively. Failure to give attention to the area of
security training puts an enterprise at great risk because security of business resources is as much a
human issue as it is a technology issue.
Technology users are the largest audience in any organization and are the single most important
group of people who can help to reduce unintentional errors and IT vulnerabilities. Users may
include employees, contractors, foreign or domestic guest researchers, other personnel, visitors,
guests and other collaborators or associates requiring access. Users must:
• Understand and comply with security policies and procedures.
• Be appropriately trained in the rules of behavior for the systems and applications to which they
have access.
• Work with management to meet training needs.
78 | P a g e
• Keep software and applications updated with security patches.
• Be aware of actions they can take to better protect company information. These actions include:
proper password usage, data backup, proper antivirus protection, reporting any suspected incidents
or violations of security policy, and following rules established to avoid social engineering attacks
and deter the spread of spam or viruses and worms.
A clear categorization of what is considered sensitive data versus non-sensitive data is also needed.
Typically, the following data are considered sensitive information that should be handled with
precaution:
• Government issued identification numbers (e.g., Social Security numbers, driver’s license numbers)
• Financial account information (bank account numbers, credit card numbers) • Medical records •
Health insurance information • Salary information • Passwords
The training should cover security policies for all means of access and transmission methods,
including secure databases, email, file transfer, encrypted electronic media and hard copies.
Employers should constantly emphasize the critical nature of data security. Regularly scheduled
refresher training courses should be established in order to instill the data security culture of your
organization. Additionally, distribute data privacy and security related news articles in your training,
and send organization-wide communication on notable data privacy related news as reminders to
your employees.
Facility Security
Protecting employees and members of the public who visit your facility is a complex and challenging
responsibility. It’s also one of your company’s top priorities.
Cyber Plan Action Items:
1. Recognize the importance of securing your company facilities
The physical security of a facility depends on a number of security decisions that can be identified
through a comprehensive risk-management process. The objective of risk management is to identify
an achievable level of protection for your company that corresponds as closely as possible to the
level of risk without exceeding the risk.
It is easy to think about physical security of your company’s facility as merely an exercise in
maintaining control of access points and ensuring there is complete visibility in areas that are
determined to be of high-risk – either because of the threat of easy public access or because of the
value of information located nearby. However, maintaining security of your company’s facility also
includes the physical environment of public spaces. For instance:
79 | P a g e
• Employees whose computers have access to sensitive information should not have their computer
monitors oriented toward publicly accessible spaces such as reception areas, check-in desks and
waiting rooms.
• Employees should be trained to not write out logins and passwords on small pieces of paper
affixed to computer equipment viewable in public spaces.
• Easy-to-grab equipment that could contain sensitive or personally identifiable information – such
as laptops, electronic tablets and cell phones – should be located away from public areas. If you have
an environment where employees are working in a waiting room or reception area, train them to
not leave these types of devices out on their desks unsecured.
• Consider implementing a badge identification system for all employees, and train employees to
stop and question anyone in the operational business area without a badge or who appears to be an
unescorted visitor.
2. Minimize and safeguard printed materials with sensitive information
Probably the most effective way to minimize the risk of losing control of sensitive information from
printed materials is to minimize the amount of printed materials that contain sensitive information.
Management procedures should limit how many instances and copies of printed reports
memoranda and other material containing personally identifiable information exist.
Safeguard copies of material containing sensitive information by providing employees with locking
file cabinets or safes. Make it a standard operating procedure to lock up important information.
Train employees to understand that simply leaving the wrong printed material on a desk, in view of
the general public, can result in consequences that impact the entire company and your customers.
3. Ensure mail security
Your mail center can introduce a wide range of potential threats to your business. Your center’s
screening and handling processes must be able to identify threats and hoaxes and eliminate or
mitigate the risk they pose to facilities, employees and daily operations. Your company should
ensure that mail managers understand the range of screening procedures and evaluate them in
terms of your specific operational requirements.
4. Dispose of trash securely
Too often, sensitive information – including customers’ personally identifiable information, business
financial and other data, and company system access information – is available for anyone to find in
the trash. Invest in businessgrade shredders and buy enough of them to make it convenient for
employees. Alternatively, subscribe to a trusted shredding company that will provide locked
containers for storage until documents are shredded. Develop standard procedures and employee
training programs to ensure that everyone in your company is aware of what types of information
need to be shredded.
80 | P a g e
5. Dispose electronic equipment securely
Be aware that emptying the recycle bin on your desktop or deleting documents from folders on your
computer or other electronic device may not delete information forever. Those with advanced
computer skills can still access your information even after you think you’ve destroyed it.
Disposing of electronic equipment requires skilled specialists in order to ensure the security of
sensitive information contained within that equipment. If outside help, such as an experienced
electronic equipment recycler and data security vendor, is not available or too expensive, you should
at a minimum remove computer hard drives and have them shredded. Also, be mindful of risks with
other types of equipment associated with computer equipment, including CDs and thumb drives.
6. Train your employees in facility security procedures
A security breach of customer information or a breach of internal company information can result in
a public loss of confidence in your company and can be as devastating for your business as a natural
disaster. In order to address such risks, you must devote your time, attention and resources
(including employee training time) to the potential vulnerabilities in your business environment and
the procedures and practices that must be a standard part of each employee’s workday.
And while formal training is important to maintaining security, the daily procedures you establish in
both the normal conduct of business and in the way you model good security behaviours and
practices are equally important. In short, security training should be stressed as critical and
reinforced via daily procedures and leadership modelling.
Operational Security
While operational security, or OPSEC, has its origins in securing information important to military
operations, it has applications across the business community today.
In a commercial context, OPSEC is the process of denying hackers access to any information about
the capabilities or intentions of a business by identifying, controlling and protecting evidence of the
planning and execution of activities that are essential the success of operations.
OPSEC is a continuous process that consists of five distinct actions:
• Identify information that is critical to your business.
• Analyze the threat to that critical information.
• Analyze the vulnerabilities to your business that would allow a cyber-criminal to access critical
information.
• Assess the risk to your business if the vulnerabilities are exploited.
• Apply countermeasures to mitigate the risk factors.
81 | P a g e
In addition to being a five-step process, OPSEC is also a mindset that all business employees should
embrace. By educating oneself on OPSEC risks and methodologies, protecting sensitive information
that is critical to the success of your business becomes second nature.
This section explains the OPSEC process and provides some general guidelines that are applicable to
most businesses. An understanding of the following terms is required before the process can be
explained:
• Critical information – Specific data about your business strategies and operations that are needed
by cyber criminals to hamper or harm your business from successfully operating.
• OPSEC indicators – Business operations and publicly available information that can be interpreted
or pieced together by a cyber-criminal to derive critical information.
• OPSEC vulnerability – A condition in which business operations provide OPSEC indicators that may
be obtained and accurately evaluated by a cyber-criminal to provide a basis for hampering or
harming successful business operations.
Cyber Plan Action Items:
1. Identity of critical information
The identification of critical information is important in that it focuses the remainder of the OPSEC
process on protecting vital information rather than attempting to protect all information relevant to
business operations. Given that any business has limited time, personnel and money for developing
secure business practices, it is essential to focus those limited resources on protecting information
that is most critical to successful business operations. Examples of critical information include, but
should not be limited to, the following:
• Customer lists and contact information
• Contracts
• Patents and intellectual property
• Leases and deeds
• Policy manuals
• Articles of incorporation
• Corporate papers
• Laboratory notebooks
• Audio tapes
82 | P a g e
• Video tapes
• Photographs and slides
• Strategic plans and board meeting minutes
Importantly, what is critical information for one business may not be critical for another business.
Use your company’s mission as a guide for determining what data are truly vital.
2. Analyze threats
This action involves research and analysis to identify likely cyber criminals who may attempt to
obtain critical information regarding your company’s operations. OPSEC planners in your business
should answer the following critical information questions:
• Who might be a cyber-criminal (e.g. competitors, politically motivated hackers, etc.)?
• What are cyber criminal’s goals?
• What actions might the cybercriminal take?
• What critical information does the cybercriminal already have on your company’s operations? (i.e.,
what is already publicly available?)
3. Analyze vulnerabilities
The purpose of this action is to identify the vulnerabilities of your business in protecting critical
information.
It requires examining each aspect of security that seeks to protect your critical information and then
comparing those indicators with the threats identified in the previous step. Common vulnerabilities
for small businesses include the following:
• Poorly secured mobile devices that have access to critical information. • Lack of policy on what
information and networked equipment can be taken home from work or taken abroad on travel.
• Storage of critical information on personal email accounts or other non-company networks. • Lack
of policy on what business information can be posted to or accessed by social network sites.
4. Assess risk
This action has two components. First, OPSEC managers must analyze the vulnerabilities identified in
the previous action and identify possible OPSEC measures to mitigate each one. Second, specific
OPSEC measures must be selected for execution based upon a risk assessment done by your
company’s senior leadership. Risk assessment requires comparing the estimated cost associated
with implementing each possible OPSEC measure to the potential harmful effects on business
operations resulting from the exploitation of a particular vulnerability.
83 | P a g e
OPSEC measures may entail some cost in time, resources, personnel or interference with normal
operations. If the cost to achieve OPSEC protection exceeds the cost of the harm that an intruder
could inflict, then the application of the measure is inappropriate. Because the decision not to
implement a particular OPSEC measure entails risks, this step requires your company’s leadership
approval.
5. Apply appropriate OPSEC measures
In this action, your company’s leadership reviews and implements the OPSEC measures selected in
the assessment of risk action. Before OPSEC measures can be selected, security objectives and
critical information must be known, indicators identified and vulnerabilities assessed.
Payment Cards
If your business accepts payment by credit or debit cards, it is important to have security steps in
place to ensure your customer information is safe. You also may have security obligations pursuant
to agreements with your bank or payment services processor. These entities can help you prevent
fraud. In addition, free resources and general security tips are available to learn how to keep
sensitive information – beyond payment information – safe.
Cyber Plan Action Items:
1. Understand and catalog customer and card data you keep
• Make a list of the type of customer and card information you collect and keep – names, addresses,
identification information, payment card numbers, magnetic stripe data, bank account details and
Social Security numbers. It’s not only card numbers criminals want; they’re looking for all types of
personal information, especially if it helps them commit identity fraud;
• Understand where you keep such information and how it is protected.
• Determine who has access to this data and if they need to have access.
2. Evaluate whether you need to keep all the data you store
• Once you know what information you collect and store, evaluate whether you really need to keep
it. Often businesses may not realize they’re logging or otherwise keeping unnecessary data until they
conduct an audit. Not keeping sensitive data in storage makes it harder for criminals to steal it;
• If you’ve been using card numbers for purposes other than payment transactions, such as a
customer loyalty program, ask your merchant processor if you can use alternative data instead.
84 | P a g e
Tokenization, for example, is technology that masks card numbers and replaces it with an alternate
number that can’t be used for fraud.
3. Use secure tools and services
• The payments industry maintains lists of hardware, software and service providers who have been
validated against industry security requirements;
• Small businesses that use integrated payment systems, in which the card terminal is connected to
a larger computer system, can check the list of validated payment applications to make sure any
software they employ has been tested;
• Have a conversation about security with your provider if the products or services you are currently
using are not on the lists.
4. Control access to payment systems
• Whether you use a more complicated payment system or a simple standalone terminal, make sure
you carefully control access.
• Isolate payment systems from other, less secure programs, especially those connected to the
Internet. For example, don’t use the same computer to process payments and surf the Internet.
• Control or limit access to payment systems to only employees who need access.
• Make sure you use a secure system for remote access or eliminate remote access if you don’t need
it so that criminals cannot infiltrate your system from the Internet.
5. Use security tools and resources
Work with your bank or processor and ask about the anti-fraud measures, tools and services you can
use to ensure criminals cannot use stolen card information at your business.
• For e-commerce retailers: - The CVV2 code is the three-digit number on the signature panel that
can help verify that the customer has physical possession of the card and not just the account
number.
- Retailers can also use Address Verification Service to ensure the cardholder has provided the
correct billing address associated with the account.
- Services such as Verified by Visa prompt the cardholder to enter a personal password confirming
their identity and providing an extra layer of protection.
• For brick and mortar retailers: - Swipe the card and get an electronic authorization for the
transaction. - Check that the signature matches the card. - Ensure your payment terminal is secure
and safe from tampering.
85 | P a g e
6. Remember the security basics
• Use strong, unique passwords and change them frequently.
• Use up-to-date firewall and anti-virus technologies.
• Do not click on suspicious links you may receive by email or encounter online.
Sample Agency Security Plan Template12
1.
Introduction
Outlines the importance of the plan and its relationship with the agencies Security Policy and
culture.
2.
Scope
This section should outline the areas of the organisation that the Plan applies to – for example is it
a plan for the whole agency or only specific portfolios or work units.
3.
Purpose and Objectives
This section should provide clear and concise statements about what the Security Plan is designed
to achieve and outline the relationship between agency security policies and processes and the
corporate plans and business objectives.
4.
Current Security Environment
This provides a summary and analysis of the agency risk assessment highlighting the current threats
and vulnerabilities along with an assessment of current security environment and treatments in
place.
5.
Security strategies and actions
This section should outline security strategies and recommended controls which need to be
implemented or maintained to achieve the desired level of agency security and a description of how
this is to be achieved and who is responsible.
6.
Residual Risks
By definition, the residual risk is the risks that remain after all possible (cost-effective) mitigation or
treatment of risks. It is important that the plan estimate, describe and rate these risks to guide the
priorities for ongoing monitoring of risks.
12
Source: Queensland Government, Chief Information Office, as at
https://www.qgcio.qld.gov.au/products/qgea-documents/549-information-security/2422-security-planexample-1-is18-toolbox, as on 9th May, 2017.
86 | P a g e
7.
Implementation Schedule
This section should provide an indication of timeframes and the key milestones in the
implementation of risk treatments and actions.
8.
Resources
This section should detail the resources and cost requirements for implementing the
recommendations outlined in the earlier section on Strategies and Actions.
9.
Review
Outline the timing and process for review of the plan.
An attempt to distill the often overwhelming amount of security policy information into a few
concise ideas13.
by eminent security authors Cyrus Peikari and Seth Fogie. But Cyrus and Seth realize that there is a
lot of information out there on policy making. In this short article, provided by InformIT, they
attempt to distill the often overwhelming amount of information into a few concise ideas.
Security policies are part of any well-maintained information system. There are numerous guides
and templates available that seem to provide you with a reference for creating the perfect security
policy. However, to the dismay of many administrators and IT managers, a good security policy is not
a simple plug-and-play component. For a policy to show any return on investment, it must become
integrated into the processes and procedures of a business, along with the support of the people
who are expected to follow it. Without this type of attention and support, a security policy will be
worthless.
Security policy design often requires weeks of testing, meetings and data analysis. These next few
pages will provide an overview of the obstacles that must be overcome in order to create the perfect
security policy. Due to the enormous amount of information available, we have attempted to
consolidate this subject into one brief section.
Defining the security policy
Over the years, there have been many attempts to define the term "security policy." There are
numerous books, articles and Web sites that deal with nothing but security policies. As a result,
there is a lot of data available to assist the policy maker, which unfortunately often has the effect of
overwhelming them. For this reason, we will look at two popular variations of a security policy
definition.
13
Source: Tech Target, as at http://searchsecurity.techtarget.com/tip/Writing-a-security-policy, as on 9th May,
2017.
87 | P a g e
The first is provided by The SANS Institute, which starts by defining a policy as "a document that
outlines specific requirements or rules that must be met...usually point-specific, covering a single
area."
In other words, SANS describes a security policy as a modular method for defining and ultimately
developing specific guidelines or rule sets that are used to control individual aspects of a computer
system, such as acceptable use, password creation or instant messaging use. Depending on the level
of security required, a company can create a few general policies that lump together multiple areas
of security, or they can create very specific itemized policies that uniquely define each threat and
then create a policy to handle that threat. The level should depend upon the value of the assets at
risk and the required level of security needed to contain the threat.
The second definition uses a more global summary. This definition is taken from an article written by
Ed Tittel in which he references SearchSecurity.com: "In business, a security policy is a document
that states in writing how a company plans to protect the company's physical and information
technology (IT) assets."
This definition highlights the purpose of the security policy verses the method of meeting this goal.
However, if you merge the two definitions, a security policy can be defined as a set of documents
that describes the security goals as required for the sole purpose of protecting the physical and
information assets of a business.
Based on this, there are many subdefinitions that can be drawn from this overview of such a
complex issue. The following will break down the security policy's purpose and how it can actually
protect your company's assets.
Document
The security policy will take the form of a document or a collection of documents depending on your
intent. From the initial assessment to the final maintenance plan, each item, standard, guideline and
procedure should be listed in a policy. This not only provides future policy creators with a guide to
create standards and guidelines, but it also helps the IT administrators develop their personal and
explicit instructions to help them meet the business goals of the policy. In addition, the policy can
also become a point of reference in case a violation occurs that results in a dismissal or other
penalty. You can expect this document to be rather long and extensive.
Security goals
First, a policy itself includes no explicit procedures to meet its own goal. This is the job of IT
administrators. However, it should be noted that the procedures should end up as part of the overall
security policy document. Instead, the policy is a "...high-level [plan] that describe the goals of the
procedures. Policies are not guidelines or standards, nor are they procedures or controls. Policies
describe security in general terms, not specifics. They provide the blueprints for an overall security
program just as a specification defines your next product." From this short excerpt of CISSP Security
Management and Practices by Roberta Bragg, you can clearly see what the security policy should
contain.
88 | P a g e
In addition to the general layout of a policy, there are some indirect goals that every security policy
should meet. As TICSA Certification: Information Security Basics describes, "...any good security
policy must address the following concerns:



Prevent waste or inappropriate use of organization resources (especially computing
resources).
Limit or eliminate potential legal liability, be it from employees or third parties.
Preserve and protect valuable, confidential or proprietary information from unauthorized
access or disclosure."
Protecting
The goals outlined in the security policy ultimately are to protect an asset. While it is important to
determine what that asset is (discussed next), you also need to determine what you are protecting
against. In other words, are you concerned about corporate espionage, theft of intellectual property,
intrusion and destruction of files from external hackers or all of the above? Determining what you
are protecting against is an important part of a security policy and needs to be determined early on
in the creation.
On the flip side, protection also involves defining where and how consequences are to be
administered in the case there is a violation. While the specifics of the rebuttals can be left to
department heads, the basic security policy needs to define the methods by which protection can be
enforced. Are authorities to be contacted? Will violations be handled in house? What are the levels
of threat? These questions and more need to be answered.
Assets
While the other sections are important, the value of the security policy is ultimately related to the
assets it is protecting. As a result, a company must perform an in-depth audit of their resources to
determine what constitutes as an asset and more importantly, the value of that asset. This can be
one of the most challenging parts of developing any security policy due to the fact that many items
are hard to put a price tag on, and others are hard to define. For example, it is easy to put a price tag
on a laptop, at least the physical value. However, how can you determine the value of the software,
programs, e-mails and other pieces of information on the drive? Not only do they have an
immediate value due to their contents, but there is also a hidden cost if another company were to
discover or steal any sensitive information.
Summary of security policies
At this point you can see how complex a security policy can be. A good security policy cannot simply
be haphazardly thrown together. In "Developing a Security Policy", written by Sun Microsystems, the
characteristics of a good security policy are defined as:


They must be implementable through system administration procedures, publishing of
acceptable use guidelines or other appropriate methods.
They must be enforceable with security tools, where appropriate, and with sanctions, where
actual prevention is not technically feasible.
89 | P a g e


They must clearly define the areas of responsibility for the users, administrators and
management.
They must be documented, distributed and communicated.
So, from this you can see that a policy must be more than a big document. If no one can understand
it or use it, the time and effort put into it will be wasted. The following section will provide you with
an example of a simple e-mail policy, along with a discussion explaining the reason for each point.
Activity 3
What should be included in a security policy and how is this different from a security plan?
90 | P a g e
Activity 3
91 | P a g e
Crafting a Technology Security Plan14
Most small-business owners understand that complete, end-to-end network security is something
they should have--but it's something they probably don't. And how can they? With security threats
coming from a multitude of sources and no end in sight to the new attacks that are frequently
launched on both networks and PCs, keeping up with all these threats and figuring out just what to
do about them is challenging enough for big companies with dedicated IT staffs. For small
businesses, it can be completely overwhelming.
The risks of not adequately securing your business network and PCs are huge, however. Remember:
It's not just your data that's at risk from attacks from viruses, spyware, hackers and others. Any
customer data stored on your computers--including Social Security numbers, bank account
information and confidential data, such as key sales and marketing data--is at risk as well.
Here are the facts, according to consumer product research organization Consumer Reports:



During a recent 24-hour monitoring period, computer security software firm Symantec
recorded 59 million attempts by hackers to gain unauthorized entry into business and home
computers.
One out of four computer users said they had experienced a major, costly problem due to a
computer virus, according to a fall 2006 survey. The average cost per incident was $109. In
addition, one out of every 115 people was the victim of a scam e-mail attack, which cost
victims an average of $850 apiece.
To combat viruses and spyware, American consumers spent at least $7.8 billion for
computer repairs, parts, and replacement over the past two years.
The Threats
Since security threats continue to evolve, business owners must not only continue to protect
themselves from existing threats such as viruses, spyware and scam e-mails, but must also keep
abreast of new threats and understand how hackers will be targeting computers in the future. So
what will the newest threats be in 2007? Here are some trends to watch:
More narrowly defined threats, or "targeted threats," are becoming common. These attacks tend
to focus on sensitive information from a single company or individual rather than indiscriminately
letting a worm loose to find victims randomly wherever they can. The "malware" capable of these
attacks is being delivered to users in increasingly sophisticated ways such as in e-mail attachments,
embedded in video files or hyperlinks, and even through social engineering tactics that lure, fool or
trick the user to make what seems like a benign action that automatically installs the malware
without user help.
Malicious bots--short for robots, or software applications that run automated tasks over the
internet --are expected to increase. Bots are sometimes used to create automated attacks on
networks, such as DoS attacks.
14
Source: Entrepreneur, as at https://www.entrepreneur.com/article/173760, as at 9th May, 2017.
92 | P a g e
Rootkits are increasingly becoming a concern. Rootkits are a set of software tools whose purpose is
to conceal processes, files or system data from a computer's operating system. Rootkits can enable
hackers to maintain access to a computer system. Because they can burrow deeply, are capable of
modifying parts of an operating system, and can go undetected, rootkits can be particularly
challenging to remove.
Zero-day attacks are also on the rise. A zero-day (also called zero hour) attack takes advantage of
computer security holes for which no solution is yet available. They're called "zero day" because
they attack between the time a security hole becomes known and the time when a patch to plug the
hole is available. As a result, zero-day attacks can spread at an alarming rate.
Identity theft will continue to be a growing concern. The FTC estimates that 10 million Americans
are victims of identity fraud each year. Hackers who gain unauthorized access to computers are
often in search of personal identity data they can exploit or sell.
The Solutions
Now that you've got some idea what you're up against, is there anything you can really do to protect
your business? Absolutely. First, you need to develop a plan that addresses both education and
technology. It's critical that you educate your users on what they can do to make sure they're not
potentially compromising security (safe user habits for reading and acting upon e-mails can prevent
many virus attacks). And make sure unauthorized users (for instance, family or friends) don't use
your business's computers.
Next, develop a comprehensive technology plan to address all aspects of security. Talk to your
trusted IT adviser. Make a complete list of the security you already have in place, with an eye toward
sniffing out vulnerabilities. Develop a plan for complete, end-to-end network protection, and make
sure there are steps in place to regularly update your security. Then revisit your plan several times a
year to ensure it continues to meet your needs and addresses new security threats that continue to
evolve.
Your plan should include the following security essentials:




Antivirus protection. Every PC on your network should have antivirus protection. There are
plenty of inexpensive, effective antivirus programs on the market for small and home
offices.
Antispyware protection. Spyware has become increasingly malicious, difficult to detect and
difficult to remove. An antispyware program that frequently downloads updated definitions
and monitors activity in the background is important, given the insidious nature of spyware.
Firewall. A firewall is designed to block unauthorized access to computers and networks.
Firewalls are available in hardware (as standalone network security devices or integrated
into network routers) or as software. A software firewall is particularly important for laptop
users who travel. Firewall software is usually included in internet security suites, which also
offer antivirus, antispyware, and other tools. Some software firewalls are even available in
free, basic versions.
Virtual private network (VPN). A VPN creates a secure "tunnel" between a computer and an
unsecured, public network, such as the internet. VPN technology offers an important layer
of protection for your business's weakest security link--mobile users.
93 | P a g e
VPN security can be integrated into some network devices, such as intelligent routers, and
turned on or off as needed.



Wireless security. If your business uses a wireless network, at a minimum, you should use
password, WEP key or some other method to block unauthorized users from gaining access.
Secure network hardware. Ideally, your company's network should be protected by routers
with comprehensive, built-in security, including integrated firewall, VPN and an intrusion
prevention system.
Data protection. Implementing regular backup procedures is a simple way to safeguard
critical business and customer data. Setting permissions and encryption will also help.
As I mentioned earlier, maintaining proper security throughout your network is a big job. If it feels
overwhelming, consider hiring an IT person to handle the job. Or outsource network security to an
independent contractor or managed service provider.
The bottom line is, would you like to be in charge of your computers, your network and your data-or would you rather leave that up to a hacker?
94 | P a g e
Identify standards against which to engineer the ICT system or application
Refer to:
AS/NZS ISO/IEC 38500:2010
ISO/IEC 38500:2008
Australian/New Zealand Standard™
Corporate governance of information technology
Download from:
http://www.professionalsaustralia.org.au/information-technology/wpcontent/uploads/sites/41/2014/11/Standards-Australia-Corporate-Governance-of-IT1.pdf
This section provides a range of information about standards directly or peripherally associated with
information security within Australia New Zealand, and elsewhere throughout the world. It does not
set out to exhaustively list all standards in the known universe that may relate primarily or
peripherally to information security15.
Those standards listed under Australia/New Zealand are those that have been developed locally. All
others are listed as international. Note that a number of international standards (eg ISO standards)
apply in Australia and New Zealand.
Australia/New Zealand

ACSI33
The Defence Signals Directorate has produced the Australian Communications Security
Instruction Number 33 (ACSI33) Security Guidelines for Australian Government IT Systems
document. This document is available at http://www.dsd.gov.au/library/infosec/acsi33.html
.

Operating System Checklists
AusCERT and the CERT Coordination Center have produced the Windows NT Configuration
Guidelines, available from http://www.auscert.org.au/render.html?it=1970
AusCERT has also produced the UNIX Computer Security Checklist, available from
http://www.auscert.org.au/render.html?it=1935
International

15
ISO/IEC 17799:2005
Source: AusCERT, as at https://www.auscert.org.au/render.html?it=2248, as on 9th May, 2017.
95 | P a g e
The primary information security standard in Australia was AS4444, and in New Zealand was
NZS4444. These have been replaced with the international standard, 17799. See Standards
Australia OnLine at http://www.standards.com.au.
Quality Assurance Services is currently coordinating a certification program for this standard.
This certification program is discussed at their Quality Assurance Services web site
(http://www.sai-global.com/assuranceservices/certification/InfoSecurityManagement/).

ISO/IEC 27001:2005
A widely accepted standard, the British Standard BS 7799 has been updated and published
as the international standard ISO/IEC 27001. It was developed by the British Standards
Institute ( http://www.bsi-global.com) and is sometimes referred to as BS ISO/IEC
27001:2005.

RFC 2196
The Internet Engineering Task Force (IETF) has produced RFC2196 Site Security Handbook,
which provides practical guidance to administrators trying to secure their information and
services. It is available from http://www.ietf.org/rfc/rfc2196.txt.

IT Baseline Protection Manual (Germany)
The Federal Agency For Security In Information Technology in Germany has produced the IT
Baseline Protection Manual. This document presents a set of recommended standard
security measures or "safeguards", as they are referred to in the manual, for typical IT
systems. The most recent version is dated October 2000. Further information can be found
at http://www.bsi.bund.de/gshb/english/etc/menue.html.

OECD Guidelines
OECD Guidelines for the Security of Information Systems, are available at
http://www.oecd.org/document/42/0,2340,en_2649_34255_15582250_1_1_1_1,00.html.
Evaluation
Australia/New Zealand

Gateway Certification Guide
The Defence Signals Directorate has also produced the Gateway Certification Guide, which
provides guidelines for independent assessment of an agency gateway. This document is
available at http://www.dsd.gov.au/library/infosec/gateway.html.
96 | P a g e

DSD EPL
The Defence Signals Directorate administers the Australian government's Evaluated Products
List. Details are available at
http://www.dsd.gov.au/infosec/evaluation_services/epl/epl.html.
International

ISO 15408 ("Common Criteria")
The International Organization for Standardization (ISO) has produced ISO standard IS
15408. This standard, The Common Criteria for Information Technology Security Evaluation
v2.1 (ISO IS 15408) is effectively an evolutionary blending of ITSEC (see below), the Canadian
criteria, and the US Federal Criteria.
It available from http://csrc.nist.gov/cc/ccv20/ccv2list.htm.

Rainbow Series ("Orange Book") (US)
An important series of documents are the Rainbow Series, which outline a number of
security standards developed in the United States. This series is available at
http://www.radium.ncsc.mil/tpep/library/rainbow/.
Perhaps the most important of these books is the Trusted Computer System Evaluation
Criteria (TCSEC, or Orange Book). While this standard has effectively been superseded by
other standards outlined above (it is dated 1985), it is nevertheless a useful document. A
further document, the US Federal Criteria, was drafted but not adopted in the early 1990's.
TCSEC can be found at http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html

Information Technology Security Evaluation Criteria ("ITSEC") (UK)
The United Kingdom produced the Information Technology Security Evaluation Criteria
(ITSEC) in the early 1990's, and this is another important historical evaluation
scheme/standard. It builds on the Orange Book scheme to some extent, with greater
granularity.
Details about the scheme are available at http://www.itsec.gov.uk/.
Development
International

Capability Maturity Model (CMM)
97 | P a g e
The Software Engineering Institute pioneered the development of the Capability Maturity
Model, which is method for process maturity assurance. Details are available at
http://www.sei.cmu.edu/cmm/cmms/cmms.html.

System Security Engineering Capability Maturity Model (SSE-CMM)
A derivative of this work is the System Security Engineering Capability Maturity Model.
Details are available at http://www.sse-cmm.org/.
Financial
Australia/New Zealand

AS2805 ("Electronic funds transfer")
Standards Australia has a standard for electronic payment implementation. The standard is
AS2805, specifically AS 2805.4-1985 Electronic funds transfer - Requirements for interfaces Message authentication and AS 2805.4.1-2001 Electronic funds transfer - Requirements for
interfaces - Message authentication - Mechanisms using a block cipher. These standards are
available by accessing the Standards Australia OnLine Catalogue and searching on Australian
standard number 2805.
International

ISO 11131 ("Banking and Related Financial Services; Sign-on Authentication")
ISO 11131:1992 Banking and Related Financial Services; Sign-on Authentication is available
by accessing the Standards Australia OnLine Catalogue and searching on ISO standard
number 11131.

ISO 13569 ("Banking and Related Financial Services -- Information Security Guidelines")
ISO 13569:1997 Banking and Related Financial Services -- Information Security Guidelines
(several documents) is available by accessing the Standards Australia OnLine Catalogue and
searching on ISO standard number 13569.
Risk
Australia/New Zealand

AS/NZS 4360 ("Risk Management")
Australian/New Zealand Standard AS/NZS 4360:1999 Risk Management. More information is
available by accessing the Standards Australia OnLine Catalogue and searching on Australian
standard number 4360.
98 | P a g e
Associated documents that may be of interest are HB 231:2000 Information security risk
management guidelines and HB 240:2000 Guidelines for managing risk in outsourcing
utilizing the AS/NZS 4360 process. More information is available by accessing the Standards
Australia OnLine Catalogue and searching on HB 231 and HB 240 respectively.
International

Acquisition Risk Management (US)
The Software Engineering Institute has some discussion on Acquisition Risk Management.
Details are available at http://www.sei.cmu.edu/arm/index.html.
Authentication
Australia/New Zealand

AS4539 ("Information technology - Public Key Authentication Framework")
Public Key authentication systems are governed by several documents that fall under
Australian Standard 4539 Information technology - Public Key Authentication Framework.
More information is available by accessing the Standards Australia OnLine Catalogue and
searching on Australian standard number 4539.
International

ISO 11131 ("Banking and Related Financial Services; Sign-on Authentication")
ISO 11131:1992 Banking and Related Financial Services; Sign-on Authentication is available
by accessing the Standards Australia OnLine Catalogue and searching on ISO standard
number 11131.
Activity 4
Select one standard applicable to ICT systems or applications and describe how you would apply
the standard to an organisation’s ICT system or application.
99 | P a g e
Activity 4
100 | P a g e
Activity 4
101 | P a g e
Identify criteria for performing risk based audits against the ICT system or
application
Taking a risk-based approach to IT audit can help focus limited resources on the real threats16
Fast-moving changes in technology have added to the potential risks companies face. It is not always
easy for senior management to wrap its arms around information technology risks confronting their
organization. However, internal audit departments can help shed light on the issue through risk-based
IT audit planning.
One way of looking at the subject is simply put: There are no IT risks as such. Rather, it is all about
business risks and how IT might impact the business.
The first step before embarking on a risk-based IT audit involves sorting out the IT audit universe. That
means pinpointing all the relevant auditable IT entities including: operating systems, databases and
networks, as well as the types of computers in the system and their physical location. Is the underlying
operating system UNIX, Windows? Is the platform a mainframe or client server? Companies taking
this approach will want to measure all of these entities and then focus their limited audit resources
on risks that could have the greatest impact on the business.
How you determine what to audit and in what sequence will be based on the risk criteria used to
identify the significance of, and likelihood that, conditions or events may occur that would hurt the
organization. Examples include the ethical climate and pressure on management to meet objectives;
competency, adequacy and integrity of personnel; financial and economic conditions; asset size,
liquidity or transaction volume; competitive conditions; and complexity or volatility of activities.
Heading the list of IT risk factors is information criticality. Think of it in terms of an acronym CIA:
Confidentiality, Integrity and Availability. These three factors are generally considered the pillars of
information security.
Confidentiality is essential to protect personally identifiable information and guard company secrets
from inadvertent disclosure. A classic example of an IT security breach happened five years ago
when the home of an employee of the U.S. Department of Veterans Affairs was burglarized and data
stored on a laptop computer– sensitive records on 26.5 million veterans— was stolen. In the
aftermath, the government made laptop hard drive encryption mandatory and many corporations
adopted the same policy.
Integrity needs to be in place in application systems so employees can trust that the output can be
relied upon for completeness and accuracy.
Availability refers to the assurance that the information is accessible to the people who require it
when they need it and that there are adequate backup and disaster recovery systems in place.
16
Source: MIS Training Institute, as at http://misti.com/internal-audit-insights/understanding-risk-based-itaudit-planning, as on 9th May, 2017.
102 | P a g e
Besides the CIA criteria, some other IT risk factors to consider include the following:
1. Materiality: Will it affect the entire company or only a part?
2. Reputational fallout: The now-defunct Arthur Andersen is frequently cited as an example of how a
damaged name can cause clients to flee.
3. Strategic plan support: Is it a new project or system? If it is, how big is it and what business risk
does it entail?
4. Fraud: What system-based controls are in place to help monitor and prevent fraudulent activity?
5. Outsourced risk: Can we rely on the controls of a third-party vendor?
6. Changes in the audit environment: Did something occur that needs a closer look? When was the
last time an audit was conducted and what was the audit opinion/conclusion?
The CIA concept avoids often-confusing technical jargon and is something everyone – from C-level
leaders to board of directors to business management can relate to.
The Institute of Internal Auditors’ Global Technology Audit Guide on IT Controls suggests a number
of basic questions for an IT risk assessment:
1. What could happen to affect an information asset value adversely (threat event)?
2. If a threat event happened, how bad could its impact be?
3. How often might the event be expected to occur?
4. What can be done to reduce the risk?
5. How much will it cost to reduce the risk?
6. Is it cost-efficient?
Identifying critical information assets and systems, based on business objectives and information
assets, is the starting point in the IT risk assessment process. What business systems house
information and support critical business functions? Is it payroll, general ledger system, or the
accounts payable system? You also will want to determine system support infrastructures (that is, IT
general controls), including hardware, operating systems, database management systems, networks
and information processing facilities.
Keep in mind, application risk drives infrastructure risk. For example, if a company identifies payroll
as a high-risk application, the IT infrastructure components that support that application get the
same risk.
How does the risk-based IT audit planning process relate to the integrated auditing concept?
By definition, integrated auditing is an integrated or coordinated effort between business audit and
technical audit to provide application audit coverage of key business risks. That is, integrated
auditing is about auditing the business process and underlying key IT components. Those conducting
an integrated audit need to audit the key supporting IT components – operating system, data base,
etc. – either before, as part of, or shortly after the integrated audit.
At some point you must look at those high-risk IT components as they relate back to the business. As
noted earlier, it’s all about business risks and how IT might impact the business.
103 | P a g e
Things get trickier when a company outsources IT functions. The risk increases in such a situation
and makes it substantially difficult to assess those controls. The question becomes: Does this thirdparty vendor have good controls? And how do you assess those controls?
Because management is accountable for the successful operation of the business, it’s important that
they understand the potential risks the organization faces through its IT system. In the past, the
conventional wisdom was that “as long as IT is doing a good job, I’m OK.” Now it’s a different ball
game: you could be in major trouble if your systems aren’t secure. Regulations such as SOX, PCI and
HIPPA have forced management to understand the potential risks to the IT system.
Remember, controls are only as good as top leadership wants to make them. Management, once
complacent about earmarking resources for IT, can no longer afford to ignore this critical
investment.
An information system (IS) audit or information technology(IT) audit is an examination of the
controls within an entity's Information technology infrastructure. These reviews may be performed
in conjunction with a financial statement audit, internal audit, or other form of attestation
engagement. It is the process of collecting and evaluating evidence of an organization's information
systems, practices, and operations. Obtained evidence evaluation can ensure whether the
organization's information systems safeguard assets, maintains data integrity, and are operating
effectively and efficiently to achieve the organization's goals or objectives17.
An IS audit is not entirely similar to a financial statement audit. An evaluation of internal controls
may or may not take place in an IS audit. Reliance on internal controls is a unique characteristic of a
financial audit. An evaluation of internal controls is necessary in a financial audit, in order to allow
the auditor to place reliance on the internal controls, and therefore, substantially reduce the
amount of testing necessary to form an opinion regarding the financial statements of the company.
An IS audit, on the other hand, tends to focus on determining risks that are relevant to information
assets, and in assessing controls in order to reduce or mitigate these risks. An IT audit may take the
form of a "general control review" or an "specific control review". Regarding the protection of
information assets, one purpose of an IS audit is to review and evaluate an organization's
information system's availability, confidentiality, and integrity by answering the following questions:
1. Will the organization's computerized systems be available for the business at all times when
required? (Availability)
2. Will the information in the systems be disclosed only to authorized users? (Confidentiality)
3. Will the information provided by the system always be accurate, reliable, and timely?
(Integrity).
The performance of an IS Audit covers several facets of the financial and organizational functions of
our Clients. The diagram to the right gives you an overview of the Information Systems Audit flow:
From Financial Statements to the Control Environment and Information Systems Platforms.
17
Source: Wiki Educator, as at http://wikieducator.org/Information_Systems_Audit_Methodology, as on 9th
May, 2017.
104 | P a g e
Information Systems Audit Methodology
Our methodology has been developed in accordance with International Information Systems Audit
Standards e.g ISACA Information Systems Audit Standards and Guidelines and the Sabarne Oxley
COSO Standard. The beginning point of this methodology is to carry out planning activities that are
geared towards integrating a Risk Based Audit Approach to the IS Audit.
PHASE 1: Audit Planning
In this phase we plan the information system coverage to comply with the audit objectives specified
by the Client and ensure compliance to all Laws and Professional Standards. The first thing is to
obtain an Audit Charter from the Client detailing the purpose of the audit, the management
responsibility, authority and accountability of the Information Systems Audit function as follows:
1. Responsibility: The Audit Charter should define the mission, aims, goals and objectives of the
Information System Audit. At this stage we also define the Key Performance Indicators and
an Audit Evaluation process;
2. Authority: The Audit Charter should clearly specify the Authority assigned to the Information
Systems Auditors with relation to the Risk Assessment work that will be carried out, right to
access the Client’s information, the scope and/or limitations to the scope, the Client’s
functions to be audited and the auditee expectations; and
3. Accountability: The Audit Charter should clearly define reporting lines, appraisals,
assessment of compliance and agreed actions.
The Audit Charter should be approved and agreed upon by an appropriate level within the Client’s
Organization.
105 | P a g e
See Template for an Audit Charter/ Engagement Letter here.
In addition to the Audit Charter, we should be able to obtain a written representation (“Letter of
Representation”) from the Client’s Management acknowledging:
1. Their responsibility for the design and implementation of the Internal Control Systems
affecting the IT Systems and processes
2. Their willingness to disclose to the Information Systems Auditor their knowledge of
irregularities and/or illegal acts affecting their organisation pertaining to management and
employees with significant roles within the internal audit department.
3. Their willingness to disclose to the IS Auditor the results of any risk assessment that a
material misstatement may have occurred
See a Template for a Letter of Representation here.
PHASE 2 – Risk Assessment and Business Process Analysis
Risk is the possibility of an act or event occurring that would have an adverse effect on the
organisation and its information systems. Risk can also be the potential that a given threat will
exploit vulnerabilities of an asset or group of assets to cause loss of, or damage to, the assets. It is
ordinarily measured by a combination of effect and likelihood of occurrence.
More and more organisations are moving to a risk-based audit approach that can be adapted to
develop and improve the continuous audit process. This approach is used to assess risk and to assist
an IS auditor’s decision to do either compliance testing or substantive testing. In a risk based audit
approach, IS auditors are not just relying on risk. They are also relying on internal and operational
controls as well as knowledge of the organisation. This type of risk assessment decision can help
relate the cost/benefit analysis of the control to the known risk, allowing practical choices.
The process of quantifying risk is called Risk Assessment. Risk Assessment is useful in making
decisions such as:
1. The area/business function to be audited
2. The nature, extent and timing of audit procedures
3. The amount of resources to be allocated to an audit
The following types of risks should be considered:
Inherent Risk: Inherent risk is the susceptibility of an audit area to error which could be material,
individually or in combination with other errors, assuming that there were no related internal
controls. In assessing the inherent risk, the IS auditor should consider both pervasive and detailed IS
controls. This does not apply to circumstances where the IS auditor’s assignment is related to
pervasive IS controls only. A pervasive IS Control are general controls which are designed to manage
and monitor the IS environment and which therefore affect all IS-related activities. Some of the
pervasive IS Controls that an auditor may consider include:

The integrity of IS management and IS management experience and knowledge
106 | P a g e






Changes in IS management
Pressures on IS management which may predispose them to conceal or misstate information
(e.g. large business-critical project over-runs, and hacker activity)
The nature of the organisation’s business and systems (e.g., the plans for electronic
commerce, the complexity of the systems, and the lack of integrated systems)
Factors affecting the organisation’s industry as a whole (e.g., changes in technology, and IS
staff availability)
The level of third party influence on the control of the systems being audited (e.g., because
of supply chain integration, outsourced IS processes, joint business ventures, and direct
access by customers)
Findings from and date of previous audits
A detailed IS control is a control over acquisition, implementation, delivery and support of IS systems
and services. The IS auditor should consider, to the level appropriate for the audit area in question:







The findings from and date of previous audits in this area
The complexity of the systems involved
The level of manual intervention required
The susceptibility to loss or misappropriation of the assets controlled by the system (e.g.,
inventory, and payroll)
The likelihood of activity peaks at certain times in the audit period
Activities outside the day-to-day routine of IS processing (e.g., the use of operating system
utilities to amend data)
The integrity, experience and skills of the management and staff involved in applying the IS
controls
Control Risk: Control risk is the risk that an error which could occur in an audit area, and which could
be material, individually or in combination with other errors, will not be prevented or detected and
corrected on a timely basis by the internal control system. For example, the control risk associated
with manual reviews of computer logs can be high because activities requiring investigation are
often easily missed owing to the volume of logged information. The control risk associated with
computerised data validation procedures is ordinarily low because the processes are consistently
applied. The IS auditor should assess the control risk as high unless relevant internal controls are:



Identified
Evaluated as effective
Tested and proved to be operating appropriately
Detection Risk: Detection risk is the risk that the IS auditor’s substantive procedures will not detect
an error which could be material, individually or in combination with other errors. In determining
the level of substantive testing required, the IS auditor should consider both:


The assessment of inherent risk
The conclusion reached on control risk following compliance testing
The higher the assessment of inherent and control risk the more audit evidence the IS auditor should
normally obtain from the performance of substantive audit procedures.
107 | P a g e
Our Risk Based Information Systems Audit Approach
A risk based approach to an Information Systems Audit will enable us to develop an overall and
effective IS Audit plan which will consider all the potential weaknesses and /or absence of Controls
and determine whether this could lead to a significant deficiency or material weakness.
In order to perform an effective Risk Assessment, we will need to understand the Client’s Business
Environment and Operations. Usually the first phase in carrying out a Risk Based IS Audit is to obtain
an understanding of the Audit Universe. In understanding the Audit Universe we perform the
following:


Identify areas where the risk is unacceptably high
Identify critical control systems that address high inherent risks
108 | P a g e

Assess the uncertainty that exists in relation to the critical control systems
In carrying out the Business Process Analysis we:



Obtain an understanding of the Client Business Processes
Map the Internal Control Environment
Identify areas of Control Weaknesses
The Chat to the right summarises the business process analysis phase.
The template xxx will provide you with a guideline to document an Organisations Business Sub
Processes identified during the risk analysis phase.For each of the sub-processes, we identify a list of
What Could Go Wrong (WCGW). This WCGW represent the threat existing on a particular process. A
single process would have multiple WCGW’s. For each of the WCGW’s identified in the prior phase
we will determine the Key Activities within that process.For each Key Activity:
1. We will identify the Information Systems Controls
2. For each of the Controls Identified, we would rate the impact/effect of the lack of that
control (on a rating of 1 - 5, with 5 indicating the highest impact),we will then determine the
likelyhood of the threat occuring( also on a rating of 1 - 5 with 5 representing the highest
likelyhood).
PHASE 3 – Performance of Audit Work
109 | P a g e
In the performance of Audit Work the Information Systems Audit Standards require us t o provide
supervision, gather audit evidence and document our audit work. We achieve this objective through:



Establishing an Internal Review Process where the work of one person is reviewed by
another, preferably a more senior person.
We obtain sufficient, reliable and relevant evidence to be obtained through Inspection,
Observation, Inquiry, Confirmation and recomputation of calculations
We document our work by describing audit work done and audit evidence gathered to
support the auditors’ findings.
Based on our risk assessment and upon the identification of the risky areas, we move ahead to
develop an Audit Plan and Audit Program. The Audit Plan will detail the nature, objectives, timing
and the extent of the resources required in the audit.
See Template for a Sample Audit Plan.
Based on the compliance testing carried out in the prior phase, we develop an audit program
detailing the nature, timing and extent of the audit procedures. In the Audit Plan various Control
Tests and Reviews can be done. They are sub-divided into:
1. General/ Pervasive Controls
2. Specific Controls
110 | P a g e
The Chat below to the left shows the Control Review Tests that can be performed in the two Control
Tests above.
Control Objectives for Information and related Technology (COBIT)
The Control Objectives for Information and related Technology (COBIT) is a set of best practices
(framework) for information (IT) management created by the Information Systems Audit and Control
Association (ISACA), and the IT Governance Institute (ITGI) in 1992.
COBIT provides managers, auditors, and IT users with a set of generally accepted measures,
indicators, processes and best practices to assist them in maximizing the benefits derived through
the use of information technology and developing appropriate IT governance and control in a
company.
111 | P a g e
COBIT helps meet the multiple needs of management by bridging the gaps between business risks,
control needs and technical issues. It provides a best practices framework for managing IT resources
and presents management control activities in a manageable and logical structure. This framework
will help optimise technology information investments and will provide a suitable benchmark
measure.
The Framework comprises a set of 34 high-level Control Objectives, one for each of the IT processes
listed in the framework. These are then grouped into four domains: planning and organisation,
acquisition and implementation, delivery and support, and monitoring. This structure covers all
aspects of information processing and storage and the technology that supports it. By addressing
these 34 high-level control objectives, we will ensure that an adequate control system is provided
for the IT environment. A diagrammatic representation of the framework is shown below.
112 | P a g e
We shall apply the COBIT framework in planning, executing and reporting the results of the audit.
This will enable us to review the General Controls Associated with IT Governance Issues. Our review
shall cover the following domains;






Planning and organisation of information resources;
The planning and acquisition of systems and path in stage growth model of information
systems;
The delivery and support of the IS/IT including facilities, operations, utilisation and access;
Monitoring of the processes surrounding the information systems;
The level of effectiveness, efficiency, confidentiality, integrity, availability, compliance and
reliability associated with the information held in; and
The level of utilisation of IT resources available within the environment of the IS including
people, the application systems of interface, technology, facilities and data.
The above control objectives will be matched with the business control objectives to apply specific
audit procedures that will provide information on the controls built in the application, indicating
areas of improvement that we need to focus on achieving.
Application Control Review
An Application Control Review will provide management with reasonable assurance that
transactions are processed as intended and the information from the system is accurate, complete
and timely. An Application Controls review will check whether:



Controls effectiveness and efficiency
Applications Security
Whether the application performs as expected
A Review of the Application Controls will cover an evaluation of a transaction life cycle from Data
origination, preparation, input, transmission, processing and output as follows:
1. Data Origination controls are controls established to prepare and authorize data to be
entered into an application. The evaluation will involve a review of source document design
and storage, User procedures and manuals, Special purpose forms, Transaction ID codes,
Cross reference indices and Alternate documents where applicable. It will also involve a
review of the authorization procedures and separation of duties in the data capture process.
2. Input preparation controls are controls relating to Transaction numbering, Batch serial
numbering, Processing, Logs analysis and a review of transmittal and turnaround documents
3. Transmission controls involve batch proofing and balancing, Processing schedules, Review of
Error messages, corrections monitoring and transaction security
4. Processing controls ensure the integrity of the data as it undergoes the processing phase
including Relational Database Controls, Data Storage and Retrieval
5. Output controls procedures involve procedures relating to report distribution, reconciliation,
output error processing, records retention.
113 | P a g e
The use of Computer Aided Audit Techniques (CAATS) in the performance of an IS Audit
The Information Systems Audit Standards require us that during the course of an audit, the IS
auditor should obtain sufficient, reliable and relevant evidence to achieve the audit objectives. The
audit findings and conclusions are to be supported by the appropriate analysis and interpretation of
this evidence. CAATs are useful in achieving this objective.
Computer Assisted Audit Techniques (CAATs) are important tools for the IS auditor in performing
audits. They include many types of tools and techniques, such as generalized audit software, utility
software, test data, application software tracing and mapping, and audit expert systems. For us, our
CAATs include ACL Data Analysis Software and the Information Systems Audit Toolkit(ISAT).
CAATs may be used in performing various audit procedures including:




Tests of details of transactions and balances(Substantive Tests)
Analytical review procedures
Compliance tests of IS general controls
Compliance tests of IS application controls
CAATs may produce a large proportion of the audit evidence developed on IS audits and, as a result,
the IS auditor should carefully plan for and exhibit due professional care in the use of CAATs. The
major steps to be undertaken by the IS auditor in preparing for the application of the selected CAATs
are:








Set the audit objectives of the CAATs
Determine the accessibility and availability of the organisation’s IS facilities,
programs/system and data
Define the procedures to be undertaken (e.g., statistical sampling, recalculation,
confirmation, etc.)
Define output requirements
Determine resource requirements, i.e., personnel, CAATs, processing environment
(organisation’s IS facilities or audit IS facilities)
Obtain access to the client’s IS facilities, programs/system, and data, including file definitions
Document CAATs to be used, including objectives, high-level flowcharts, and run instructions
Make appropriate arrangements with the Auditee and ensure that:
1. Data files, such as detailed transaction files are retained and made available before the
onset of the audit.
2. You have obtained sufficient rights to the client’s IS facilities, programs/system, and data
3. Tests have been properly scheduled to minimise the effect on the organisation’s production
environment.
4. The effect that changes to the production programs/system have been properly considered.
See Template here for example tests that you can perform with ACL
PHASE 4: Reporting
114 | P a g e
Upon the performance of the audit test, the Information Systems Auditor is required to produce and
appropriate report communicating the results of the IS Audit. An IS Audit report should:
1. Identify an organization, intended recipients and any restrictions on circulation
2. State the scope, objectives, period of coverage, nature, timing and the extend of the audit
work
3. State findings, conclusions, recommendations and any reservations, qualifications and
limitations
4. Provide audit evidence
Activity 5
What is a risk based audit?
115 | P a g e
Activity 5
116 | P a g e
Activity 5
The Internet continues to grow exponentially. Personal, government, and business applications
continue to multiply on the Internet, with immediate benefits to end users. However, these
network-based applications and services can pose security risks to individuals and to the information
resources of companies and governments. Information is an asset that must be protected. Without
adequate network security, many individuals, businesses, and governments risk losing that asset18.
18
Source: Love My Tool, as at http://www.lovemytool.com/files/vulnerabilities-threats-and-attacks-chapterone-7.pdf, as on 9th May, 2017.
117 | P a g e
Network security is the process by which digital information assets are protected. The goals of
network security are as follows:
 Protect confidentiality
 Maintain integrity
 Ensure availability
With this in mind, it is imperative that all networks be protected from threats and vulnerabilities for
a business to achieve its fullest potential.
Typically, these threats are persistent because of vulnerabilities, which can arise from the following:
Not all required commands are covered in sufficient detail in the text alone. Successful completion
of this course requires a thorough knowledge of command syntax and application.





Misconfigured hardware or software
Poor network design
Inherent technology weaknesses
End-user carelessness
Intentional end-user acts (that is, disgruntled employees)
Introduction to Network Security
This chapter consists of an overview of what network security is all about. The sections that follow
cover the following aspects of network security:





The need for network security
Identifying potential risks to network security
Open versus closed security models
Trends driving network security
Information security organizations
The Need for Network Security
Security has one purpose: to protect assets. For most of history, this meant building strong walls to
stop the enemy and establishing small, well-guarded doors to provide secure access for friends. This
strategy worked well for the centralized, fortress-like world of mainframe computers and closed
networks, as seen in Figure 1-1.
118 | P a g e
The closed network typically consists of a network designed and implemented in a corporate
environment and provides connectivity only to known parties and sites without connecting to public
networks. Networks were designed this way in the past and thought to be reasonably secure
because of no outside connectivity.
With the advent of personal computers, LANs, and the wide-open world of the Internet, the
networks of today are more open, as shown in Figure 1-2.
As e-business and Internet applications continue to grow, the key to network security lies in defining
the balance between a closed and open network and differentiating the good guys from the bad
guys.
With the increased number of LANs and personal computers, the Internet began to create untold
numbers of security risks. Firewall devices, which are software or hardware that enforce an access
control policy between two or more networks, were introduced. This technology gave businesses a
balance between security and simple outbound access to the Internet, which was mostly used for email and web surfing.
119 | P a g e
This balance was short-lived as the use of extranets began to grow, which connected internal and
external business processes. Businesses were soon realizing tremendous cost savings by connecting
supply-chain management and enterprise resource planning systems to their business partners, and
by connecting sales-force automation systems to mobile employees, and by providing electronic
commerce connections to business customers and consumers. The firewall began to include
intrusion detection, authentication, authorization, and vulnerability-assessment systems. Today,
successful companies have again struck a balance by keeping the enemies out with increasingly
complex ways of letting friends in.
Most people expect security measures to ensure the following:
 Users can perform only authorized tasks.
 Users can obtain only authorized information.
 Users cannot cause damage to the data, applications, or operating environment of a system.
The word security means protection against malicious attack by outsiders (and by insiders).
Statistically, there are more attacks from inside sources. Security also involves controlling the effects
of errors and equipment failures. Anything that can protect against an attack will probably prevent
random misfortunes, too.
Throughout this book, many definitions, acronyms, and logical device symbols dealing with security
are introduced (see Figure 1-3). Refer to the glossary for further explanation when encountering
unknown terms and acronyms.
120 | P a g e
Identifying Potential Risks to Network Security
A risk analysis should identify the risks to the network, network resources, and data. The intent of a
risk analysis is to identify the components of the network, evaluate the importance of each
component, and then apply an appropriate level of security. This analysis helps to maintain a
workable balance between security and required network access. The key is to identify what needs
to be secured and at what cost. More money and assets would be allocated ensuring the security of
a high-priced automobile versus an old junker, for example.
Asset Identification
Before the network can be secured, you must identify the individual components that make up the
network. You need to create an asset inventory that includes all the network devices and endpoints,
such as hosts and servers.
Vulnerability Assessment
After you have identified the network components, you can assess their vulnerabilities. These
vulnerabilities could be weaknesses in the technology, configuration, or security policy. Any
vulnerability you discover must be addressed to mitigate any threat that could take advantage of the
vulnerability. Vulnerabilities can be fixed by various methods, including applying software patches,
reconfiguring devices, or deploying countermeasures, such as firewalls and antivirus software. Many
websites list the vulnerabilities of network components, and the manufacturers of operating systems
and components that list vulnerabilities of their products sponsor many websites.
Threat Identification
A threat is an event that can take advantage of vulnerability and cause a negative impact on the
network. Potential threats to the network need to be identified, and the related vulnerabilities need
to be addressed to minimize the risk of the threat.
Open Versus Closed Security Models
121 | P a g e
With all security designs, some trade-off occurs between user productivity and security measures.
The goal of any security design is to provide maximum security with minimum impact on user access
and productivity. Some security measures, such as network data encryption, do not restrict access
and productivity. On the other hand, cumbersome or unnecessarily redundant verification and
authorization systems can frustrate users and prevent access to critical network resources.
Remember that the network is a tool designed to enhance production. If the security measures that
are put in place become too cumbersome, they will actually detract rather than enhance
productivity. Networks used as productivity tools should be designed so that business needs dictate
the security policy. A security policy should not determine how a business operates. Because
organizations are constantly subject to change, security policies must be systematically updated to
reflect new business directions, technological changes, and resource allocations.
Security policies vary greatly in design. Three general types of security models are open, restrictive,
and closed. Some important points are as follows (see Figure 1-4):



Security model can be open or closed as a starting point.
Choose the best end-to-end mix of security products and technology to implement the
model.
Application-level security can include Secure Sockets Layer (SSL) technology.
Like security models, many devices can be classified as open, restrictive, or closed. For example,
routers and switches are typically open devices, allowing high functionality and services by default.
On the other hand, a firewall is typically a closed system that does not allow any services until they
are switched on. Server operating systems can fall into any of the three categories, depending on the
vendor. It is important to understand these principles when deploying these devices.
122 | P a g e
Open Access
An open security model is the easiest to implement, as shown in Figures 1-5 and 1-6. Few security
measures are implemented in this design. Administrators configure existing hardware and software
basic security capabilities. Firewalls, virtual private networks (VPNs), intrusion detection systems
(IDSs), and other measures that incur additional costs are typically not implemented. Simple
passwords and server security become the foundation of this model. If encryption is used, it is
implemented by individual users or on servers.
123 | P a g e
This model assumes that the protected assets are minimal, users are trusted, and threats are
minimal. However, this does not exclude the need for data backup systems in most open security
policy scenarios. LANs that are not connected to the Internet or public WANs are more likely to
implement this type of model.
This type of network design gives users free access to all areas. When security breaches occur, they
are likely to result in great damage and loss. Network administrators are usually not held responsible
for network breaches or abuse.
Restrictive Access
A restrictive security model is more difficult to implement, as shown in Figures 1-7 and 1-8. Many
security measures are implemented in this design. Administrators configure existing hardware and
software for security capabilities in addition to deploying more costly hardware and software
solutions such as firewalls, VPNs, IDSs, and identity servers. Firewalls and identity servers become
the foundation of this model.
124 | P a g e
This model assumes that the protected assets are substantial, some users are not trustworthy, and
that threats are likely. LANs that are connected to the Internet or public WANs are more likely to
implement this type of model. Ease of use for users diminishes as security tightens.
125 | P a g e
Closed Access
A closed security model is most difficult to implement. All available security measures are
implemented in this design. Administrators configure existing hardware and software for maximumsecurity capabilities in addition to deploying more costly hardware and software solutions such as
firewalls, VPNs, IDSs, and identity servers, as shown in Figures 1-9 and 1-10.
126 | P a g e
The closed security model assumes that the protected assets are premium, all users are not
trustworthy, and that threats are frequent. User access is difficult and cumbersome. Network
administrators require greater skills and more time to administer the network. Furthermore,
companies require a higher number of and better trained network administrators to maintain this
tight security. In many corporations and organizations, these administrators are likely to be
unpopular while implementing and maintaining security. Network security departments must clarify
that they only implement the policy, which is designed, written, and approved by the corporation.
Politics behind the closed security model can be monumental. In the event of a security breach or
network outage, network administrators might be held more accountable for problems.
Trends Driving Network Security
As in any fast-growing industry, changes are to be expected. The types of potential threats to
network security are always evolving. If the security of the network is compromised, there could be
serious consequences, such as loss of privacy, theft of information, and even legal liability. Figure 111 illustrates several threats and their potential consequences.
127 | P a g e
128 | P a g e
Develop processes and procedures to mitigate the introduction of
vulnerabilities during the engineering process
Information Technology Threats and Vulnerabilities19
A threat and a vulnerability are not one and the same. A threat is a person or event that has the
potential for impacting a valuable resource in a negative manner. A vulnerability is that quality of a
resource or its environment that allows the threat to be realized. An armed bank robber is an
example of a threat. A bank teller is an example of a valuable resource that may be vulnerable
during a bank robbery. Bullet-proof glass between the robber and the teller denies the robber the
opportunity to shoot the teller. The threat remains present, but one of its harmful effects (a
gunshot) has been mitigated by a protection mechanism (the glass).
In system and network security, the threats remain present but are mitigated through the proper
use of security features and procedures. Mitigation is any effort to prevent the threat from having a
negative impact, or to limit the damage where total prevention is not possible, or to improve the
speed or effectiveness of the recovery effort.
Hardware and software systems and the data they process can be vulnerable to a wide variety of
threats.
19
Source: NASA, as at https://www.hq.nasa.gov/security/it_threats_vulnerabilities.htm, as on 9th May, 2017.
129 | P a g e
The selection of security features and procedures must be based not only on general security
objectives but also on the specific vulnerabilities of the system in question in light of the threats to
which the system is exposed. It is possible to over-protect, which only wastes resources and
inconveniences users.
As you can see, there is a relationship between threats and vulnerabilities. Sometimes it is easier to
examine each potential threat and determine the extent to which you are vulnerable (e.g. fire, flood,
earthquake). In other cases it is easier to look for potential vulnerabilities with no particular threat in
mind (e.g. improper mounting of equipment, media failure, data entry error). In order to arrive at a
complete risk assessment, both perspectives must be examined. Threats and vulnerabilities are
intermixed in the following list and can be referred to collectively as potential "security concerns."
For ease of discussion and use, concerns can be divided into four categories. Environmental
concerns include undesirable site-specific chance occurrences such as lightning, dust and sprinkler
activation. Physical concerns include undesirable site-specific personnel actions, either intentional or
unintentional, such as theft, vandalism and trip hazards. Site-Support concerns include foundational
site aspects such as electrical power, telephone service and climate control. These three categories
of concerns are generally not resolvable as part of system design and administration - they are more
appropriately addressed as part of facility design and maintenance, thereby encompassing all
systems present.
The final category, Technical concerns, includes insidious system-specific situations such as improper
system operation, malicious software and line tapping. The actual threats are few: untrained and
nefarious users and system calamities. It is far more useful to explore the many avenues
(vulnerabilities) open to these users and events, and to consider ways to prevent these occurrences
and/or provide for rapid recovery.
The following list is meant to be used as a starting point in any IT risk assessment. Each potential
concern must be evaluated for a particular site or system to determine the extent to which it
applies. The probability of its occurrence, coupled with the projected impact of the event and the
cost of the appropriate mitigation yields a prioritized list of security concerns that should be
addressed.
Environmental (undesirable site-specific chance occurrences)












Fire
Flood
Tsunami
Earthquake
Volcanic Eruptions
Lightning
Severe Weather
Smoke
Dust
Insects
Rodents
Chemical Fumes
130 | P a g e






Sprinkler Activation
Water Leakage - pipe breakage, hole in roof, condensation
Explosion - nearby gas line, chemical plant, tank farm, munitions depot
Vibration - nearby railroad track, jet traffic, construction site
Electromagnetic Interference - suggested by poor radio reception or jittery workstation
displays
Electrostatic Discharge - suggested by "sparking" to grounded objects
Physical (undesirable site-specific personnel actions)















Unauthorized Facility Access
Theft
Vandalism
Sabotage
Extortion
Terrorism / Bomb Threat
Labor Unrest - employees and support contractors
War / Civil Unrest
Improper Transportation - equipment dropped, submerged, exposed to weather or X-rayed
in transit
Improper Mounting/Storage - equipment exposed to bumps, kicks or weather
Spillage / Droppage - hazardous materials permitted near equipment (e.g. food, liquids)
Magnets / Magnetic Tools - can erase data or damage sensitive equipment
Collision - fork lift, auto, plane, wheelchair
Trip Hazards / Falls - equipment poses personnel hazards
Fire Hazards - flammable materials stored nearby
Site-Support (foundational site aspects)












Power Outage
Extreme / Unstable Temperatures
Extreme / Unstable Humidity
Unsafe Environment - unfit for human occupation
Facility Inaccessibility - blocked ingress
Inability to Cut Power - during fire, flood, etc.
Electrical Noise / Bad Ground - suggested by flickering lights or jittery workstation displays
Improper Maintenance - unqualified support or preventive maintenance behind schedule
Personnel Unavailability - inability to contact operations or support personnel
Telephone Failure - inability to contact site from outside, inability to call out, service
completely unavailable
Inappropriate Fire Suppression - water, foam, PKP, Halon
Inappropriate Trash Disposal - sensitive data released in an unauthorized manner
Technical (insidious system-specific situations)

Improper / Inadequate Procedure - foreseeable events not supported by complete and
accurate documentation and training
131 | P a g e

























Improper Operation - operating equipment beyond capacity or outside of manufacturer's
constraints
Improper Hardware Configuration - prescribed hardware configured in other than the
prescribed manner during installation
Improper Software Configuration - prescribed software configured in other than the
prescribed manner during installation
Unauthorized Hardware / Modification - adding other-than-prescribed hardware or making
unauthorized hardware modifications
Unauthorized Software / Modification - adding other-than-prescribed software or making
unauthorized software modifications
Unauthorized Software Duplication - creating copies of licensed software that are not
covered by a valid license
Unauthorized Logical Access - acquiring the use of a system for which no access has been
authorized (as opposed to gaining physical access to the hardware)
Malfeasance (exceeding authorizations) - acquiring the use of a system in excess of that
which has been authorized
Unsanctioned Use / Exceeding Licensing - utilizing authorized system resources for
unauthorized purposes (resume, church bulletin, non-job-related e-mail or Internet
browsing) or exceeding a user licensing agreement
Over- or Under-Classification - labelling of a resource at a higher or lower level of sensitivity
than appropriate
Malicious Software - software whose purpose is to degrade system performance, modify or
destroy data, steal resources or subvert security in any manner
Hardware Error / Failure [functionality] - hardware that stops providing the desired user
services/resources
Hardware Error / Failure [security] - hardware that stops providing the desired security
services/resources
Software Error / Failure [functionality] - software that stops providing the desired user
services/resources
Software Error / Failure [security] - software that stops providing the desired security
services/resources
Media Failure - storage media that stops retaining stored information in a retrievable/intact
manner
Data Remanence - storage media that retains stored information in a retrievable/intact
manner longer than desired (failure to totally erase)
Object Reuse - a system providing the user with a storage object (e.g. memory or disk space)
that contains useful information belonging to another user
Communications Failure / Overload - a communications facility that stops providing service
or is unable to provide service at the requested capacity
Communications Error - a communications facility that provides inaccurate service
Data Entry Error - a system accepting erroneous data as legitimate
Accidental Software Modification / Deletion - deleting or otherwise making unavailable
necessary software
Accidental Data Modification / Deletion - deleting or otherwise making unavailable
necessary data
Accidental Data Disclosure - inadvertently revealing sensitive data to an unauthorized user
Repudiation - participating in a process or transaction but then denying having done so
132 | P a g e






Masquerading - participating in a process or transaction but posing as another user
Message Playback - recording a legitimate transmission for retransmission at a later time in
an attempt to gain unauthorized privileges
Message Flooding - generating an inordinately large quantity of transmissions in an attempt
to make a system or service unavailable due to overload
Line Tapping - connecting to a communications facility in an unauthorized manner in an
attempt to glean useful information
Electronic Emanations - information-bearing spurious emissions associated with all
electronic equipment (prevented by TEMPEST equipment or shielding)
Geo-location - a system inadvertently revealing the current physical location of a user
NOTE: The above list of Technical concerns is somewhat generic but is useful during system
design and remains useful at a high level during system audits; a more detailed list of
system-specific vulnerabilities would be so long and dynamic as to be unmanageable automated tools should be used to identify operating system-, application- and middleware-specific vulnerabilities.
Eliminating Vulnerabilities Upfront20
The final security architecture and non-technical controls should attempt to eliminate as many of
the security vulnerabilities as possible, and assuage the others as appropriate, given the threat- and
asset value-based budget considerations. This is a subtle but very important point.
Some would-be system vulnerabilities can be eliminated altogether by modifying the business or IT
processes. If the value of the asset and the extent of the threat warrant, eliminating a vulnerability is
often more effective than developing a set of technical or non-technical controls to mitigate it.
Another consideration is how to mitigate or recover from the impact of malicious or harmful activity,
either deliberate or inadvertent, that can impact the business. Examples of mitigation practices are
developing a recovery or failover capability to deal with Denial of Service incidents, incorporating the
public relations team in the security incident response process to help "media spin" a public
embarrassment, or creating backups to assuage the loss of or damage to an asset.
Architecture Defined
Architecture means many things to many people. For the purposes of this report, architecture is a
set of principles and directions (a road map) that guides the engineering process and product
selection. It includes detailed design; product selection; construction; implementation; support; and
management of an organization’s information systems and technology infrastructure.2 is NOT simply
an approved product list or a network diagram.
Architecture
An architecture can be formulated at multiple levels. For example, an organization can define an
enterprise-wide architecture that guides all development activities, including information systems
and infrastructure development (networks, servers, middleware, etc.). An enterprise-wide
architecture helps steer discrete projects towards a desired future state. In this context, architecture
enables organizations to develop systems that meet business goals and objectives over a period of
time.
20
Source: METASeS, as at http://horseproject.wiki/images/3/38/Secure-System-Development-Life-Cycle.pdf,
as on 10th May, 2017.
133 | P a g e
Architecture also can refer more specifically to a subnetwork or a specific business system. Such a
system-level architecture typically includes a more specific set of goals and requirements that drive
the system design. In this discussion, we will refer to system-level security architecture as it applies
to a specific business system project. Our focus is on only the Information Security aspects -- the
technical and non-technical controls used to achieve the business security goals. In this document,
we will spend the majority of time discussing the technical control mechanisms.
The line between architecture and system design is often blurry. In its pure form, which is rarely
encountered "in the wild", architecture is expressed as a set of goals or requirements. Design, on the
other hand, is the integration of the hardware, software, processes, and procedures required to
achieve the goals. For example, security architecture may express the goal of restricting perimeter
network access, but would not necessarily mandate a specific firewall, which might fall under
design’s purview.
Academic musing about the split between architecture and design is not important. What is critical is
that you express the architecture at some level in terms of specific goals or requirements.
Iterative Steps: Practice Makes Perfect
We will walk through this phase, like the others, in a linear series of steps. However, note that
finalizing the architecture and designing a security solution is often in practice an iterative process,
that is, it requires several passes to get it right. The idea behind these repetitions is to catch design
level vulnerabilities that can be mitigated or effectively removed through a change in design. For
example, a help desk often performs the function of resetting user passwords. This can introduce
vulnerabilities into the system if the help desk employees have access to the system tools used to
change the passwords. You could permit customers to reset their passwords themselves (with the
appropriate authentication processing of course), or provide the help desk with only "reset"
capabilities. Such steps would remove the vulnerability outright.
In the first iteration, you review the requirements set forth in the previous requirements analysis
phase, along with the current enterprise-wide technical architecture or enterprise-wide security
architecture and processes. With those items as input, you will begin to formulate the system-level
Information Security architecture.
Architecture’s Twin Components
The architecture will have two components:
1. Technical Controls -- System controls defined in the architecture and enumerated in a system
design. Technical controls might include methods such as data redundancy and tools such as
Redundant Array of Independent Disks (RAID) to achieve the security goal of data availability, or
token-based authentication methods like SecureID cards, to attain the confidentiality goal.
2. Non-Technical Controls -- Controls embodied in processes and procedures. For example:
134 | P a g e
• Dual Entry – The requirement of multiple signatures or approvals to allow a sensitive transaction to
proceed.
• Separation of Duties – The separation out of business functions so that no one individual has sole
responsibility for a type of transaction.
• Audit Reviews – The review of processes in an attempt to identify malfunctions or inconsistencies
in operation.
• Awareness Programs – Training courses or internal advertising to help modify potentially harmful
end-user behaviours
System-Level Architecture Development
Formulating system-level security architecture is basically a process of inputs and outputs. In this
section, we will illustrate both the traditional architecture development process, and a "fast path"
method for meeting some of the stringent time requirements of the new Internet business world.
Key Inputs
The fundamental security goals are one of the main inputs to the system-level security architecture
of a Web or e-Commerce business system. The key inputs to the system-level security architecture
derive from the requirements analysis tasks above. They include:







Security Goals
Assets
Threats
Activities
Current and Future Business Direction
Infrastructure
External Regulatory Requirements and Corporate Security Policy
Vulnerability Management21
Vulnerability management (VM) is the cyclical practice of identifying, classifying, remediating, and
mitigating vulnerabilities. This is a broad definition that has implications for corporate or
government entities. It is not a new discipline, nor is it a new technology. This vital function has been
a normal part of hardening defences and identifying weaknesses to systems, processes, and
strategies in the military and in the private sector. With growing complexity in organizations, it has
become necessary to draw out this function as a unique practice complete with supporting tools.
This has resulted in an important refinement of the definition of VM as a segment of risk
management.
21
Source: Information System Security, as at
http://www.infosectoday.com/Articles/Intro_Vulnerability_Management.htm, as on 9th May, 2017.
135 | P a g e
The Role of Risk Management
Risk management seeks to identify the conditions or events under which a loss may occur, and then
find the means to address that risk. Addressing risk can take the following forms:
Accept the risk; that is, do nothing and let it happen. This is also known as retention. Mitigate the
risk; that is, prevent it from happening. Reduce the risk; that is, reduce the consequences by actions
such as ensuring against the event.
In VM, we look at risks resulting from flaws in systems, processes, and strategies. Figure 1.1 shows
the relationship of VM with a risk management program. The purpose is to discover and address
risks that result from vulnerabilities under the control or influence of the organization. Other aspects
of risk management related to event probability analysis and continuity management are not
directly concerned with vulnerabilities.
Figure 1.1 Role of vulnerability management in risk management framework.
136 | P a g e
VM typically focuses attention on technical software and system configuration vulnerabilities. There
are also vulnerabilities related to corporate strategy, economics, and the environment whose
detection cannot be automated. They require the attention of a risk manager.
These vulnerabilities exist in areas such as business processes, strategies, and supply chains. Every
action or plan that a business has could be exploited through design flaws or a lack of adaptability. It
is the larger role of the risk manager to recognize and address these challenges. In this book, we
discuss primarily technical software and system configuration vulnerabilities; however, some
attention is also given to vulnerabilities related to corporate strategy, economics, and the
environment.
Origins of Vulnerability Management
Vulnerability Management has been around for a long time yet few have paid attention to it until
recently. The military has long understood and perfected VM through ritual and practice. Inspections
of defences from the organization and deployment strategy down to the individual soldier and
weapons are the equivalent of audits. The recursive training, equipping, and rearrangement of
defences is a form of remediation or hardening. But these activities have not come without an
understanding of the enemy.
A student of military history can easily recognize how one opponent vanquished another by
exploiting a vulnerability or strategic error. These victors are often hailed as geniuses, rather than
the losers being seen as incompetent. Consider, for example, the battle of Cannae where Hannibal
collapsed his centre line to envelop the Romans so that he could attack from all sides, thereby
defeating them. Hannibal is considered a genius for this now-classic tactic. However, one might also
see this as a flawed strategy of Varro, one of the Roman consuls at the battle. Varro believed that
the Roman army could drive through the centre of Hannibal's front line and drive the entire enemy
line to the river at their backs. What he did not consider was the essential discipline for maintaining
a uniform front line, which was undeniably a vulnerability.
Yet, in the business world we tend to view the failure to be prepared for risk as an example of
incompetence. This is especially true when the corporation is generally perceived as being strong,
wealthy, and able to dedicate the resources to addressing risk.
As an IT discipline, VM has been immature and its users naïve about its application: immature
because strong, enterprise-ready technology is only now becoming available, and naïve because the
need for a complete, integrated solution with well-defined processes has not been fully recognized.
Although military discipline may not seem necessary in a corporate environment, the lack of
discipline leads to the one key vulnerability that is not discovered or not remediated, and which may
eventually lead to catastrophic losses.
Introducing the Security Industry and Its Flaws
Not so surprisingly, corporations and government alike have relied on new products to "bolt on"
security to their networks. The security industry has focused on selling products and services that
require upgrades and maintenance. If there is a security problem that seems to emerge, a vendor
has developed a solution. When users started abusing network ports to reach into other host
services in a remote network, the industry gave us firewalls. When viruses became a problem, the
industry offered us anti-virus software and services.
137 | P a g e
When worms like Sasser were found, anti-virus vendors put more anti-virus functionality in the
network. When in-house applications became more of a target, application firewalls were offered.
Unfortunately, very few of these solutions seem to address the central problem. Most security
problems result from a failure to code, patch, configure, or design in a secure manner. This is the
military equivalent to a lack of training of the troops, lack of oversight by commanders, and failure to
provide adequate equipment. Just as technology vendors continue to provide us with productized
solutions, you can hand the troops all the weapons that can be bought but these will not be the
targets of your enemy. The product purchase scenario is a strategic failure.
It is not my intent to disparage the use of these and other security technologies. They are an
important part of an overall security strategy. However, while all of these bad things were
happening, few people were focused on identifying and fixing what was exploited, and none of these
technologies can fully make up for a failure to use strong passwords or keep shrink-wrapped
software patched.
The value of most security products in a network comes from their ability to temporarily mitigate
risks for which you do not have a more permanent or reliable solution. The anti-virus product is a
good idea so long as you get updates quickly and those updates are accurate. When the latest virus
comes out, the product should quickly be prepared to stop it until the vendor of the target software
supplies a patch. Eventually, the virus will find its way into the organization and around some
defences. The important thing is to get a permanent fix in place before that happens.
Challenges from Government and Industry
The IT department faces many other challenges from the governments of the world. Varying degrees
of legislation from one jurisdiction to another create a minefield of legal and operational challenges.
Multinational companies are particularly challenged. In some countries, regulators and labor unions
treat intrusion detection with suspicion, on the grounds that it may be an invasion of privacy. In
other countries, the collection of Internet surfing activity for a particular user is compulsory and
must be supplied to the authorities upon request. Vague yet onerous regulations such as SarbanesOxley (SOX) in the United States have resulted in a multitude of security controls that offer little
value but considerable expense. This makes active defence of a network in a globally managed
package an even bigger challenge because security managers must now differentiate compliance
activities from those that bring real security.
Add to all of this the industry standards for security controls and the associated certifications and
audits. The alphabet grows constantly: SAS 70, SOX § 404, ISO 17799, ISO 27001, PCI, FIPS, HIPAA,
GLB, IEEE P1074, EAL. Standards and certification are important, but they often distract us from our
most central problems: vulnerable software, architecture, and strategy. There is no long-term
substitute for well-written, tested, and properly configured software deployed thoughtfully with
solid practices.
Sources of Vulnerabilities
Software companies are also a real challenge to software buyers everywhere. Their coding practices
can stand a lot of improvement, as can their basic designs. Some want to sell more products, so they
continue to introduce more functionality without securing what was built before. A new electronic
communications protocol or new application using that protocol is developed.
138 | P a g e
But they never secure the protocol from the beginning. The vendors also do a fairly poor job of
notifying users and issuing patches. The problem is motivational because they see patching as a cost
greater than the benefit since no one is paying for the additional development work. In some cases,
a vendor is entrenched in the market and customers have few alternatives. The cost of changing
software makers can be expensive for a company with thousands of units deployed and hundreds of
trained support staff.
Example of Flawed Vulnerability Management
When we do perform the VM function, it is usually half-heartedly. One company attempted to
deploy VM agents throughout the enterprise as an act of payment card industry (PCI) compliance.
The auditors told them they should do it, and so they did it without regard to the benefit or the
effect. As a result, the only tangible requirement was that the technology be deployed. No one
considered what would happen after that. Obvious questions such as "on which hosts do we install
the agents?" and "what vulnerabilities do we have to fix first?" were ignored. I refer to this as the
check box security strategy. Someone to whom a company has delegated authority provides a
checklist of what to fix, and then the company complies.
Another obvious problem with this security approach is that a tool that can help address the root
cause of so many vulnerabilities would have no official owner. Instead, in my example, the agents
and server were installed without anyone to maintain them. No matter how hard you try,
maintenance does not happen by itself. Someone has to read the reports, repair or reinstall
components or agents, and make sure the reporting server stays healthy. Someone also has to
monitor the overall system to make sure that it achieves its objectives. This is the equivalent of
deploying a division of troops without a leader. They would be badly coordinated and ineffective.
Why Vulnerability Management Is Important
For a corporation, resources are quite limited. It can only spend so much on a risk, so an early
analysis of risks is certainly important. However, I would argue that there is little excuse for not
performing the VM function. It seems difficult to justify spending limited funds on intrusion
detection or security event management when VM has not been implemented. Although VM
involves more complex processes and systems, the risk profile of a company can look quite different
when there are fewer critical vulnerabilities to defend.
In this book, you will find far more than a description of the technology and a few tips on how to get
it going. You will gain an in-depth understanding of how VM works from both a technology
perspective and a process perspective. Neither one is very useful without the other. Technology
tools are facilitators of the process. Much time will be spent understanding this. Experience in the
uniqueness of your company's environment will bring you to the realization that only those who are
very serious about having a strong, secure infrastructure are needed. Anything else is a waste of
money and time.
You will also gain an understanding of the strategic significance of vulnerabilities and their control.
Beyond the concern for a single host or network device, vulnerabilities can exist at other levels that
can only be addressed by adjustment to the technology strategy. It is risk management at an
organization and industry level, and transcends any technology.
139 | P a g e
Ways to Mitigate Overlooked Network Security Risks22
The vast majority of information security incidents aren't caused by highly-sophisticated,
unprecedented technological exploitation. In fact, the bulk of security incidents are caused by just
ten known security vulnerabilities or humans who fall prey to phishing attacks. Significantly reducing
your company's risk of data breach requires organizations to mitigate the most commonly
overlooked risks.
The breadth of the security field may be responsible for an organization's overlooked vulnerabilities.
While one company may be an expert at applying necessary patches, the security policy may be well
out-of-date. A competitor may have strong technological safeguards, but sloppy mobile protection.
Best practices and regulatory compliance require organizations to take a comprehensive approach to
risk management. In this blog, we'll define 10 of the most commonly overlooked security risks and
discuss best practices for mitigation.
1. Mobile Devices
Mobile devices are a critical tool for worker productivity. A CIOInsight study indicates workers may
gain as many as nine hours per week of additional productivity when given access to a smartphone,
tablet, or another device. However, these devices can introduce a wide array of risks and
vulnerabilities to the enterprise.
Some of the most common mobile-related risks can include:
22
Source: Cimcor, as at http://www.cimcor.com/blog/10-smart-ways-to-mitigate-overlooked-networksecurity-risks, as on 9th May, 2017.
140 | P a g e




Device theft
Communication interception
Mobile malware
User risks (sharing devices)
How to Mitigate Mobile Device Risk:




Mobile device management (MDM) technology can improve oversight and the ability to
maintain consistent, on-time security updates to mobile devices.
Ensure your Acceptable Use Policies include clear guidelines for company and employeeowned mobile devices.
Agent-based file integrity monitoring software can enable negative change detection on
devices, even if they aren't connected to your company network.
Carefully weigh the risks and benefits of a Bring-Your-Own-Device (BYOD) policy and
whether it's worth implementation at your organization.
2. Portable Storage Devices
Portable storage devices like USB drives have the potential to both leak and introduce data to your
network. While many organizations have chosen to introduce policies which prohibit the use of USB
flash drives and other portable storage devices to mitigate risks, some are still reliant upon these
business tools. If your organization is still using portable storage devices, it's wise to consider better
controls around these items or an alternative like cloud-based file sharing.
How to Mitigate Portable Storage Device Risk



Consider turning off ports in your desktops to completely prevent use. This can be
accomplished with Windows Active Directory.
Provide employees with alternatives to portable storage devices for data-sharing needs
such as cloud-based file sharing options.
Address portable storage devices in your security policy; include clear guidelines for use or
the complete prohibition of use.
3. Poor Password Management
A shocking number of passwords are still set as "admin" or "default" due to poor password
governance and control. These vulnerabilities can occur when IT professionals vow to change
passwords "later" and fail to follow-up. Other forms of poor organizational control, such as minimal
password standards or infrequent password changes, can result in network security risks.
How to Mitigate Poor Password Management Risk:



Implement technical safeguards to enforce appropriate passwords and changes.
Address policies and penalties for employee password sharing in your security policy.
Fully encrypt all stored passwords in compliance with PCI-DSS standards.
141 | P a g e
4. Poor Authentication Requirements
Single-factor authentication can allow unauthorized access to go undetected for long periods of
time. While most security managers are familiar with the basics of access authentication—
knowledge of credentials and possession of a known device—additional factors may be necessary
for adequate security.
The 2016 Verizon Data Breach Investigation Report (DBIR) indicates a shocking number of data
breaches occur after criminals gain access with credentials either stolen through phishing or hacked
with brute force. Think of authentication as a critical sidekick to better password management which
can help detect unauthorized access to an authorized account.
How to Mitigate Poor Authentication Requirements:


Implement, at a minimum, a two-factor authentication for users to gain successful access.
Consider adding time and location of access as additional authentication factors.
5. Default Software Installations
Vulnerabilities in systems and applications can occur in both vendor-produced and home-grown IT
solutions. Failing to update software can maximize risks. The ten most common technical
vulnerabilities accounted for over 85% of data breaches in the past year. It's crucial to shift towards
an active model of identifying and remediating threats based on known vulnerabilities in your
software configurations.
How to Mitigate Application Risk:



Deploy all updates from vendors to your software immediately.
Actively identify and remediate risks in both vendor-supplied and homegrown applications.
Follow appropriate change control procedures every time configurations are changed or
updated.
6. Missing Patches
A single missing patch can weaken your entire network, leaving you vulnerable to attack. If your
company's data ecosystem is complex, it can be easy to lose control of patch updates and let
patches on utility servers go well out-of-date. However, this can introduce a significant vulnerability
that organizations simply can't afford.
How to Mitigate the Risk of Missing Patches:


Apply patch updates regularly in accordance with PCI requirements.
Continue monitoring your critical files for negative changes during scheduled patch updates,
instead of turning off file integrity monitoring software during update periods.
7. Insider Threats
142 | P a g e
In a recent TechRepublic poll, 76% of pros noted that "insider threats" are their biggest network
security concern. In most cases, insider risks originate from poor knowledge or carelessness which
can lead to human error or ignored policies and procedures.
More rarely, insiders with malicious intent can wreak havoc due to first-hand knowledge of system
vulnerabilities and technical workarounds. Examples of organizational factors that may put you at
risk of realized insider threats can include:




Minimal training,
Poor new hire screening,
Excessive user access, and
Unchecked administrative "super" users.
How to Mitigate Insider Threats:



Implement behaviorally-driven training and metrics to measure the results of your
awareness programs.
Create comprehensive access governance policies to ensure users have the minimum
degree of necessary access.
Systemize daily review of your audit lots and log review and ensure your logs cannot be
edited by super users.
8. Poor Configuration Choices
In many cases, default configurations can introduce a great deal of risk into network security. An
expert review of your firewall rule bases could reveal a number of vulnerabilities because they aren't
a good match for your organization's security needs.
How to Mitigate Poor Configuration:


Ensure your security policy is comprehensive
Use policy to guide firewall configuration rule bases.
9. Insufficient Policy
Without a comprehensive security policy, it is difficult to control and enforce positive behaviors in an
enterprise. Your policy should be a guiding force behind your IT and employee-led efforts to mitigate
risks. Per PCI, "All employees should be aware of the sensitivity of cardholder data and their
responsibilities for protecting it."
If your policy leaves any room for questions, it's probably long overdue for an update. The following
risk mitigation recommendations are influenced by PCI compliance standards, which represent best
practices even for organizations that are not required to comply.
How to Mitigate Policy Risk:

Review and revise your policy at least once per calendar year.
143 | P a g e



Develop daily, weekly, and monthly security procedures, and assign each of these
responsibilities clearly to capable personnel.
Address acceptable usage of computers, mobile, and other devices.
Define the organization-wide responsibility to protect information for all employees, and
ensure every employee is aware of this responsibility.
10. Infrequent File Integrity Monitoring
PCI requirements 10.5.5. and 11.5 require file integrity monitoring at least once per week. However,
failing to monitor more frequently and certain forms of file integrity monitoring can fail to mitigate
your network vulnerabilities. Agentless file integrity monitoring may only observe changes in
throughput, which can neglect the detection of negative changes on certain network devices.
Going a full week or longer between scans can allow unauthorized access to your network to go
undetected for days or more. As the DBIR reminds us, 82% of data breaches are complete in a
minutes or less. Without real-time file integrity monitoring software, your organization could fail to
notice you're under attack until it's far too late to stop anything.
How to Mitigate Integrity-Based Risks:


Implement real-time, agent-based file integrity monitoring software.
Consider a solution which allows full, real-time remediation of negative changes.
Get the Fundamentals Right
Many of the most commonly-overlooked network vulnerabilities are relatively simple. Out-of-date
patches and default passwords can place companies at risk for a successful information security
attack. By using compliance, policy, and best-of-class security technologies to guide your security
program, you can approach vulnerabilities with the systemic ability to search and destroy risks.
Activity 6
Provide an example of one risk that should be mitigated during system design.
144 | P a g e
Activity 6
145 | P a g e
Activity 6
Data correlated from Metasploit and Microsoft Security Patch Information (covering 16 months
between mid-2013 to late 2014) found that the points below could assist in mitigating up to 95% of
exploits, which affect Windows, Internet Explorer, and Microsoft Office23.
1. Require administrators to use standard accounts unless actively performing an administrative
task.
Many organizations do not look at elevated privileges as a security threat despite the fact many
breaches are designed to exploit users running as administrator. Implementing any type of
privileged desktop elevation solution which permits a standard user to perform a limited number of
administrative tasks would greatly improve security. Such a solution would allow administrators to
define which applications or tasks can run with elevated privileges while preventing unapproved
software installs, accidental execution of malicious software/scripts, and browsing the web when a
user is actively logged on as an administrator.
2. Run the latest major version of Microsoft Windows, Office, and Internet Explorer
Experience has taught us that identifying and patching vulnerabilities is a fundamental aspect to
security. Most malware leverages vulnerabilities to exploit systems. Oddly what is also very effective
is running the latest major versions, even without patching. This is not to suggest you should not
patch but point out that Windows 8 is essentially Windows 7 with all the security patches rolled in at
the time of release. The same concept applies to Office 2013 vs. Office 2010 or Internet Explorer 11
vs. Internet Explorer 10.
3. Contain and alert on what is leaving your network (Egress filtering)
Monitoring and/or denying certain outbound traffic is not so much about preventing a breach,
rather, it’s focused on containment of sensitive data after a breach has occurred. There are
numerous examples where custom malware traffic is designed to communicate over port 443 and
23
Source: Windows IT Pro, as at http://windowsitpro.com/security/4-steps-mitigate-95-known-vulnerabilities
146 | P a g e
something as simple as an authenticated web proxy could prevent this traffic from leaving the
network.
Savvy malware writers have been known to encrypt data leaving networks, making it difficult to
determine the content of the data, thus, the value in data analysis lies in determining traffic
patterns, sources and destinations to limit the amount of information lost.
4. Implement Multi-factor Authentication
“Death to passwords” is a rally cry we have heard for almost a decade. Although it is unlikely that a
large corporate network could completely eliminate passwords, we can significantly reduce
password vulnerability by introducing additional factors for authentication. What multi-factor
authentication adds is strength that a compromised password alone is not valuable as they do not
have the required token to successfully logon.
There are numerous options when it comes to multi-factor authentication including OTP (One Time
Password), RFID, Smart Card, Fingerprint Reader, or Retina Scanner. Although a layperson may not
recognize the term Multi-factor authentication, it is already used by most adults in the US
today. The ATM card in your wallet that also has a pin number is the perfect example of two factor
authentication used to secure a valuable asset.
Staying up-to-date on security patches, limiting the use of administrator level rights, and
implementing a multi-factor authentication protocol into your environment could assist in mitigating
up to 95% of exploits based on the data evaluated. These measures, along with a good Egress
filtering strategy, in case you are ever hacked, are the most effective ways to reduce the potential of
being breached.
No matter what approach your organization chooses to take, the most important thing you can do is
continuously monitor and review your security practices. Attackers are always evolving and refining
their methods, so, you too must be diligent and take the steps necessary to ensure you are properly
protected.
When discussing network security, the three common terms used are as follows:



Vulnerability—A weakness that is inherent in every network and device. This includes
routers, switches, desktops, servers, and even security devices themselves.
Threats—The people eager, willing, and qualified to take advantage of each security
weakness, and they continually search for new exploits and weaknesses.
Attacks—The threats use a variety of tools, scripts, and programs to launch attacks against
networks and network devices. Typically, the network devices under attack are the
endpoints, such as servers and desktops.
The sections that follow discuss vulnerabilities, threats, and attacks in further detail.
147 | P a g e
Vulnerabilities
Vulnerabilities in network security can be summed up as the “soft spots” that are present in every
network. The vulnerabilities are present in the network and individual devices that make up the
network.
Networks are typically plagued by one or all of three primary vulnerabilities or weaknesses:



Technology weaknesses
Security policy weaknesses
Configuration weaknesses
Technological Weaknesses
Computer and network technologies have intrinsic security weaknesses. These include TCP/IP
protocol weaknesses, operating system weaknesses, and network equipment weaknesses. Table 1-3
describes these three weaknesses.
Configuration Weaknesses
148 | P a g e
Network administrators or network engineers need to learn what the configuration weaknesses are
and correctly configure their computing and network devices to compensate. Table 1-4 lists some
common configuration weaknesses.
Security Policy Weaknesses
Security policy weaknesses can create unforeseen security threats. The network can pose security
risks to the network if users do not follow the security policy. Table 1-5 lists some common security
policy weaknesses and how those weaknesses are exploited.
149 | P a g e
Threats
There are four primary classes of threats to network security, as Figure 1-12 depicts. The list that
follows describes each class of threat in more detail.
150 | P a g e




Unstructured threats—Unstructured threats consist of mostly inexperienced individuals
using easily available hacking tools such as shell scripts and password crackers. Even
unstructured threats that are only executed with the intent of testing and challenging a
hacker’s skills can still do serious damage to a company. For example, if an external company
website is hacked, the integrity of the company is damaged. Even if the external website is
separate from the internal information that sits behind a protective firewall, the public does
not know that. All the public knows is that the site is not a safe environment to conduct
business.
Structured threats— Structured threats come from hackers who are more highly motivated
and technically competent. These people know system vulnerabilities and can understand
and develop exploit code and scripts. They understand, develop, and use sophisticated
hacking techniques to penetrate unsuspecting businesses. These groups are often involved
with the major fraud and theft cases reported to law enforcement agencies.
External threats—External threats can arise from individuals or organizations working
outside of a company. They do not have authorized access to the computer systems or
network. They work their way into a network mainly from the Internet or dialup access
servers.
Internal threats—Internal threats occur when someone has authorized access to the
network with either an account on a server or physical access to the network. According to
the FBI, internal access and misuse account for 60 percent to 80 percent of reported
incidents.
151 | P a g e
As the types of threats, attacks, and exploits have evolved, various terms have been coined to
describe different groups of individuals. Some of the most common terms are as follows:







Hacker—Hacker is a general term that has historically been used to describe a computer
programming expert. More recently, this term is commonly used in a negative way to
describe an individual who attempts to gain unauthorized access to network resources with
malicious intent.
Cracker—Cracker is the term that is generally regarded as the more accurate word that is
used to describe an individual who attempts to gain unauthorized access to network
resources with malicious intent.
Phreaker—A phreaker is an individual who manipulates the phone network to cause it to
perform a function that is normally not allowed. A common goal of phreaking is breaking
into the phone network, usually through a payphone, to make free long-distance calls.
Spammer—A spammer is an individual who sends large numbers of unsolicited e-mail
messages. Spammers often use viruses to take control of home computers to use these
computers to send out their bulk messages.
Phisher—A phisher uses e-mail or other means in an attempt to trick others into providing
sensitive information, such as credit card numbers or passwords. The phisher masquerades
as a trusted party that would have a legitimate need for the sensitive information.
White hat—White hat is a term used to describe individuals who use their abilities to find
vulnerabilities in systems or networks and then report these vulnerabilities to the owners of
the system so that they can be fixed.
Black hat—Black hat is another term for individuals who use their knowledge of computer
systems to break into systems or networks that they are not authorized to use.
Attacks Four primary classes of attacks exist:




Reconnaissance
Access
Denial of service
Worms, viruses, and Trojan horses The sections that follow cover each attack class in more
detail.
Reconnaissance
Reconnaissance is the unauthorized discovery and mapping of systems, services, or vulnerabilities
(see Figure 1-13). It is also known as information gathering and, in most cases, it precedes an actual
access or denial-of-service (DoS) attack. Reconnaissance is somewhat analogous to a thief casing a
neighbourhood for vulnerable homes to break into, such as an unoccupied residence, easy-to-open
doors, or open windows.
152 | P a g e
Access
System access is the ability for an unauthorized intruder to gain access to a device for which the
intruder does not have an account or a password. Entering or accessing systems to which one does
not have authority to access usually involves running a hack, script, or tool that exploits a known
vulnerability of the system or application being attacked.
Denial of Service (DoS)
Denial of service implies that an attacker disables or corrupts networks, systems, or services with the
intent to deny services to intended users. DoS attacks involve either crashing the system or slowing
it down to the point that it is unusable. But DoS can also be as simple as deleting or corrupting
information. In most cases, performing the attack simply involves running a hack or script. The
attacker does not need prior access to the target because a way to access it is all that is usually
required. For these reasons, DoS attacks are the most feared.
153 | P a g e
Worms, Viruses, and Trojan Horses
Malicious software is inserted onto a host to damage a system; corrupt a system; replicate itself; or
deny services or access to networks, systems or services. They can also allow sensitive information
to be copied or echoed to other systems. Trojan horses can be used to ask the user to enter sensitive
information in a commonly trusted screen. For example, an attacker might log in to a Windows box
and run a program that looks like the true Windows logon screen, prompting a user to type his
username and password. The program would then send the information to the attacker and then
give the Windows error for bad password. The user would then log out, and the correct Windows
logon screen would appear; the user is none the wiser that his password has just been stolen. Even
worse, the nature of all these threats is changing—from the relatively simple viruses of the 1980s to
the more complex and damaging viruses, DoS attacks, and hacking tools in recent years. Today,
these hacking tools are powerful and widespread, with the new dangers of selfspreading blended
worms such as Slammer and Blaster and network DoS attacks. Also, the old days of attacks that take
days or weeks to spread are over. Threats now spread worldwide in a matter of minutes. The
Slammer worm of January 2003 spread around the world in less than 10 minutes. The next
generations of attacks are expected to spread in just seconds. These worms and viruses could do
more than just wreak havoc by overloading network resources with the amount of traffic they
generate, they could also be used to deploy damaging payloads that steal vital information or erase
hard drives. Also, there is a strong concern that the threats of tomorrow will be directed at the very
infrastructure of the Internet.
Vulnerability Analysis
Before adding new security solutions to an existing network, you need to identify the current state
of the network and organizational practices to verify their current compliance with the
requirements. This analysis also provides you with the opportunity to identify possible
improvements and the potential need to redesign a part of the system or to rebuild a part of the
system from scratch to satisfy the requirements. This analysis can be broken down into the following
steps:
1. Policy identification
2. Network analysis
3. Host analysis
The remainder of this chapter looks at each of these steps in more depth and at some analysis tools.
Policy Identification If a security policy exists, the designer should analyze it to identify the security
requirements,
which will influence the design of the perimeter solution. Initially, the designer should examine two
basic areas of the policy:
154 | P a g e


The policy should identify the assets that require protection. This helps the designer provide
the correct level of protection for sensitive computing resources and to identify the flow of
sensitive data in the network.
The policy should identify possible attackers. This gives the designer insight into the level of
trust assigned to internal and external users, ideally identified by more-specific categories
such as business partners, customers of an organization, and outsourcing IT partners.
The designer should also be able to evaluate whether the policy was developed using correct riskassessment procedures. For example, did the policy development include all relevant risks for the
organization and not overlook important threats? The designer should also reevaluate the policy
mitigation procedures to determine whether they satisfactorily mitigate expected threats. This
ensures that the policy, which the designer will work with, is current and complete. Organizations
that need a high level of security assurance will require defense-in-depth mechanisms to be
deployed to avoid single points of failure. The designer also needs to work with the organization to
determine how much investment in security measures is acceptable for the resources that require
protection.
The result of policy analysis will be as follows:


The evaluation of policy correctness and completeness
Identification of possible policy improvements, which need to be made before the security
implementation stage
Network Analysis
Many industry best practices, tools, guides, and training are available to help secure network
devices. These include tools from Cisco, such as AutoSecure and Cisco Output Interpreter, and from
numerous web resources. Third-party resources include the U.S. National Security Agency (NSA)
Cisco Router Security Recommendation Guides and the Center for Internet Security (CIS) Router
Audit Tool (RAT) for auditing Cisco router and PIX Security Appliance configuration files.
Cisco AutoSecure
The Cisco AutoSecure feature is enabled from a Cisco IOS Security command-line interface (CLI)
command, as shown in Table 1-6. AutoSecure enables rapid implementation of security policies and
procedures to ensure secure networking services. It enables a “one-touch” device lockdown process,
simplifying the security configuration of a router and hardening the router configuration. This
feature simplifies the security process, thus lowering barriers to the deployment of critical security
functionality.
155 | P a g e
Cisco Output Interpreter
The Cisco Output Interpreter (see Figure 1-28) is a troubleshooting tool that report potential
problems by analyzing supported show command output. The Output Interpreter is available at the
Cisco website to users with a valid Cisco.com.
156 | P a g e






Output Interpreter supports the following functionality:
Displays show command output from a router, switch, or PIX Security Appliance. A list of
supported show commands is available at the Output Interpreter site.
Displays error messages generated by a router, switch, or PIX Security Appliance. The error
or log messages can be copied and pasted from a router, switch, or PIX Security Appliance
into the Output Interpreter.
Decodes and analyzes a router or switch stack trace for any possible bugs. Copy and paste
the show version command output followed by traceback or stack trace and alignment data.
Can convert the apply, conduit, and outbound statements of a PIX Security Appliance
configuration to equivalent access-list statements. Copy and paste show tech-support or
write terminal command output of the PIX Security Appliance.
Decodes and analyzes the Configuration Register. Copy and paste the show version or show
tech-support command output into the Output Interpreter.
Figure 1-29 shows an example of the output of the Output Interpreter.
157 | P a g e
Integrate applicable information security requirements, controls, processes,
and procedures into ICT system and application design specifications
according to established requirements
Acquisition / Development Phase –
– Risk Assessment – analysis that identifies the protection requirements for the system through a
formal risk assessment process. This analysis builds on the initial risk assessment performed
during the Initiation phase, but will be more in-depth and specific.
– Security Functional Requirements Analysis – analysis of requirements that may include the
following components: (1) system security environment, (i.e., enterprise information security
policy and enterprise security architecture) and (2) security functional requirements
– Security Assurance Requirements Analysis – analysis of requirements that address the
developmental activities required and assurance evidence needed to produce the desired level of
confidence that the information security will work correctly and effectively. The analysis, based on
legal and functional security requirements, will be used as the basis for determining how much
and what kinds of assurance are required.
– Cost Considerations and Reporting – determines how much of the development cost can be
attributed to information security over the life cycle of the system. These costs include hardware,
software, personnel, and training
– Security Planning – ensures that agreed upon security controls, planned or in place, are fully
documented. The security plan also provides a complete characterization or description of the
information system as well as attachments or references to key documents supporting the
agency’s information security program (e.g., configuration management plan, contingency plan,
incident response plan, security awareness and training plan, rules of behavior, risk assessment,
security test and evaluation results, system interconnection agreements, security
authorizations/accreditations, and plan of action and milestones).
– Security Control Development – ensures that security controls described in the respective
security plans are designed, developed, and implemented. For information systems currently in
operation, the security plans for those systems may call for the development of additional security
controls to supplement the controls already in place or the modification of selected controls that
are deemed to be less than effective.
– Developmental Security Test and Evaluation – ensures that security controls developed for a
new information system are working properly and are effective. Some types of security controls
(primarily those controls of a non-technical nature) cannot be tested and evaluated until the
information system is deployed—these controls are typically management and operational
controls.
158 | P a g e
– Other Planning Components – ensures that all necessary components of the development
process are considered when incorporating security into the life cycle. These components include
selection of the appropriate contract type, participation by all necessary functional groups within
an organization, participation by the certifier and accreditor, and development and execution of
necessary contracting plans and processes.
Organizations today, from small businesses with Web and email access to multisite global
enterprises, face increasingly sophisticated attacks carried out over the Internet. Once an attacker
gains access to internal networks, the damage that ensues can be catastrophic, resulting in data
disclosures and destruction, business disruption and damage to an organization's reputation. Even
with solid perimeter defences (e.g., firewalls, intrusion detection/prevention systems, VPNs and so
on), hardened systems and endpoint protection, security breaches still occur. The question is when
and how will these security breaches happen?24
The attack surface of an IT environment changes constantly. As new computers and devices are
installed, operating systems and applications are upgraded and firewall rules are changed, causing
new vulnerabilities to be introduced. One way to find out how attackers could breach network
defences and damage internal servers, storage systems and endpoints -- and the data they hold and
transfer -- is to discover and close those vulnerabilities. That's where vulnerability management tools
come into play.
What is vulnerability management?
Vulnerability management is a continuous process of discovering, prioritizing and mitigating
vulnerabilities in an IT environment. Although vulnerability management tools vary in strength and
feature sets, most include the following:



Discovery: The process of identifying and categorizing every asset in a networked
environment and storing attributes in a database. This phase also includes discovering
vulnerabilities associated with those assets.
Prioritization: The process of ranking known asset vulnerabilities and risk. Vulnerabilities are
assigned a severity level, such as from 1 to 5, with 5 being the most critical. Some systems
rank vulnerabilities as low, medium and high.
Remediation/Mitigation: The system provides links to information about each vulnerability
discovered, which includes recommendations for remediation and vendor patches, where
applicable. Some vendors maintain their own vulnerability intelligence database
information; others provide links to third-party resources such as The MITRE Corporation's
Common Vulnerabilities and Exposures database, the Common Vulnerability Scoring System
and/or the SANS/FBI Top 20, to name a few.
24
Source: tech Target, as at http://searchsecurity.techtarget.com/feature/Introduction-to-vulnerabilitymanagement-tools, as on 9th May, 2017.
159 | P a g e
Organizations tackle the most severe vulnerabilities first and work their way down to the least
severe as time and resources permit.
Some vulnerabilities don't pose a serious threat to the organization and may simply be accepted,
which means they are not remediated. In other words, the risk is judged to be less than the costs of
remediation.
How do vulnerability management tools work?
Vulnerability management tools come in three primary forms: stand-alone software, a physical
appliance with vulnerability management software or a cloud-hosted service. A customer uses a
Web-based interface to configure the product to scan a range of Internet Protocol (IP) addresses -both IPv4 and IPv6 -- the entire network or URL, and may select other criteria to inspect, such as the
file system, configuration files and/or the Windows registry. The more criteria and the larger the
number of IPs, the longer a scan takes to complete. Most vulnerability management tools provide
preconfigured scans, and an administrator can modify those templates to save customized scans
that run on demand or on a scheduled basis.
Note: Highly penetrating scans that assess "hard-to-reach" areas of a network may require an
administrator to temporarily modify a firewall to get the most detailed results, although some
vendors claim their products can perform complete scans without any such firewall modifications.
A comprehensive vulnerability scanner should be able to perform continuous inventorying of wired
and wireless devices, operating systems, applications including Web apps, ports, services, protocols,
as well as virtual machines and cloud environments.
Vulnerability management tools may perform authenticated and unauthenticated vulnerability
scans. An unauthenticated scan does not require administrative credentials and focuses on basic
issues, such as open ports and services, identity of operating systems and so on. Authenticated scans
typically require admin credentials and are more intense, and they may negatively impact a system
or network. Although authenticated scans must be used cautiously, usually outside of peak usage
hours, they reveal more vulnerabilities than unauthenticated ones.
When a vulnerability management tool is put in place, the initial scan that's run should be as
complete as possible. This also serves to establish a baseline. Subsequent scans then show trends
and help administrators understand the security posture of the environment over time. Most
vulnerability management products provide detailed trend analysis reports and charts for display on
the console or in print for distribution to managers and executives.
Some of these products also include exploit software that's used as a penetration test tool. When
vulnerabilities are exposed, an administrator can use the exploit software to see how an attacker
could exploit the vulnerability without disrupting network operations.
A vulnerability management tool must be used regularly to be effective. Like antivirus products, the
data gathered during scans is only as good as the last time it was updated. This means daily scans for
most organizations; although small environments or those whose critical assets are not exposed to
the Internet may find a weekly scan sufficient.
160 | P a g e
Who needs vulnerability management tools?
Organizations of all sizes -- from small to midsize businesses (SMBs) to enterprises -- with access to
the Internet can benefit from vulnerability management. Customers from nearly every industry and
vertical niche use vulnerability management, including education, banking and financial services,
government, healthcare, insurance, manufacturing, retail (bricks-and-mortar and online), technology
and many more.
How are vulnerability management tools sold?
Vulnerability management products may be sold as software-only products, a physical appliance
with vulnerability management software or as a cloud-hosted service. When purchasing vulnerability
management software, customers can expect to pay either an upfront cost and/or licensing and
ongoing maintenance fees. The same applies to a physical appliance and software combo, and in this
case, the customer also pays for the initial cost of the appliance. Some vendors offer appliance
licensing, just like software, to enable organizations to treat the entire purchase as operational
expenditure rather than capital expenditure.
A cloud-hosted service or software as a service offering is typically sold as an annual subscription
that includes unlimited scanning. Vendor cloud pricing varies, and may be based on the number of
users, IPs -- either active only or total scanned -- and/or agents deployed. Customers can save
money by using services that charge only by active IP, which enables them to scan all IPs on a
network, but pay only for those currently in use.
Even the smallest of organizations (i.e., those with less than 25 users) need some type of
vulnerability management tool, but it's a critical part of a sound security posture for SMBs and
enterprises. For organizations that must meet compliance measures, such as HIPAA, Gramm-LeachBliley and PCI DSS, vulnerability management is required.
National Security Agency (NSA) Cisco Router Security Configuration Guides The Router Security
Configuration Guide (RSCG) contains principles and guidance for secure configuration of IP routers,
with detailed instructions for Cisco Systems routers (http://www.nsa.gov/snac/routers/cisco_scg1.1b.pdf). The RSCG was used extensively in the development of the Cisco Router Security course.
This guide was developed in response to numerous questions and requests for assistance received
by the NSA System and Network Attack Center (SNAC). The topics covered in the guide were
selected on the basis of customer interest, community consensus, and the SNAC’s background in
securing networks. The RSCG is a large, detailed, yet readable and accessible document. It is
supplemented with an Executive Summary Card, a quick checklist for securing your Cisco router.
Routers direct and control much of the data flowing across computer networks. The RSCG provides
technical guidance intended to help network administrators and security officers improve the
security of their networks. Using the information presented here, you can configure your routers to
control access, resist attacks, shield other network components, and even protect the integrity and
confidentiality of network traffic.
161 | P a g e
The goal for this guide is a simple one: improve the security provided by routers on U.S. government
operational networks.
The RSCG document is only a guide to recommended security settings for IP routers, particularly
routers running Cisco IOS Software Release 11 and 12. It is not meant to replace well designed policy
or sound judgment. The guide does not address site-specific configuration issues. Care must be
taken when implementing the security steps specified in this guide. Ensure that all security steps and
procedures chosen from this guide are thoroughly tested and reviewed prior to implementing them
on an operational network.
Cisco IOS XR Software
Cisco IOS XR Software, a new member of the Cisco IOS family, is a unique self-healing and selfdefending operating system designed for always-on operation while scaling system capacity up to 92
Tbps. Cisco IOS XR powers the Cisco Carrier Routing System, enabling the foundation for network
and service convergence today while providing investment protection for decades to come.
Cisco Router Audit Tool (RAT)
The CIS RAT is based on the CIS Benchmark for Cisco IOS routers, a consensus-based best practice
guideline for hardening Cisco routers. Version 2.2 of the RAT tool can be used to score both Cisco
IOS routers and PIX Security Appliances. The RAT is available for the Windows or UNIX operating
systems. Example 1-1 shows a sample RAT output display. The RAT downloads configurations of
devices to be audited (optionally) and then checks them against the settings defined in the
benchmark.
162 | P a g e
For each configuration examined, the RAT produces a report listing the following:




A list of each rule checked with a pass/fail score
A raw overall score
A weighted overall score (1–10)
A list of commands that will correct problems identified
The RAT produces a composite report listing all rules (settings) checked on all devices (and an overall
score) and recommendations for improving the security of the router, as shown in Figure 1-30.
163 | P a g e
Host Analysis
The hosts that are on the network need to be considered when designing a network security
solution. Determining the role in the network of each host will help to decide the steps that will be
taken to secure it. The network could have many user workstations, and multiple servers that need
to be accessed from both inside and outside of the network.
The types of applications and services that are running on the hosts need to be identified, and any
network services and ports that are not necessary should be disabled or blocked. All operating
systems should be patched as needed. Antivirus software should be installed and kept current. Some
servers may be assigned static routable IP addresses to be accessible from the Internet. These hosts
in particular should be monitored for signs of malicious activity.
Many tools are available to test host security. Most tools have been developed on a UNIX or Linux
platform, and some of them have now been ported to other operating systems. Two of the most
common tools are as follows:


Network Mapper (Nmap)—Nmap is a popular free tool used for security scanning and
auditing. It can rapidly perform a port scan of a single host or a range of hosts. Nmap was
originally written to be run on UNIX systems, and it is now available for use on Microsoft
Windows platforms, as shown in Figure 1-31.
Nessus—Nessus is a vulnerability scanner that is available for UNIX and Microsoft Windows
platforms. New vulnerability testing capabilities can be added to Nessus through the
installation of modular plug-ins. Nessus includes a built-in port scanner, or it can be used
along with Nmap. When the Nessus scan is finished, a report is created. This report displays
the results of the scan and provides steps to mitigate vulnerabilities.
164 | P a g e
Analysis Tools
Many tools are available to help to determine vulnerabilities in endpoint devices, such as network
hosts and servers. You can obtain these tools from either the company that creates the operating
system or a third party. In many cases, these tools are free. The sections that follow describe some
of the most commonly used analysis tools.
Knoppix STD
Knoppix Security Tools Distribution (STD) is a Linux LiveCD distribution that contains many valuable
security tools. The LiveCD is a bootable CD-ROM that contains the Linux operating system, along
with software applications, that can be run from memory without installation on the hard drive.
After the LiveCD is ejected from the CD-ROM drive, the system can be rebooted to return to the
original operating system. Knoppix STD contains many useful features, such as the following:









Encryption tools
Forensics tools
Firewall tools
Intrusion detection tools
Network utilities
Password tools
Packet sniffers
Vulnerability assessment tools
Wireless tools
Many additional versions of LiveCD are available. If one distribution does not support a particular
system or piece of hardware, it might be necessary to try another distribution. Most LiveCD releases
are available as free downloads that the end user can burn to a CD.
165 | P a g e
Microsoft Baseline Security Analyzer
You can use the Microsoft Baseline Security Analyzer (MBSA) to scan hosts running Windows 2000,
Windows XP, and Windows Server 2003 operating systems to determine potential security risks.
MBSA scans for common system misconfigurations and missing security updates. MBSA includes
both a graphical interface and a CLI that can perform local or remote scans. After a system scan, the
MBSA provides a report outlining potential vulnerabilities and the steps required to correct them.
This tool is available as a free download from Microsoft.
Architecture/Design Considerations
There are two sets of architecture/design considerations:
1. First order, business-focused considerations 2. Second order, technical considerations
The output of the first set of discussions, completed in the requirements phase, will provide the grist
for another series of more technical discussions that cover the second-order architectural/design
considerations. These include:
• Business and IT Operational Considerations –
- Characterization of business operational and IT operational items that may impact the security
architecture. For example:
- How will new customers be set up and by whom?
- How will users of the system be updated (e.g., password resets, changes in access rights), or
removed from the system?
- Will disparate systems be maintained, or are plans in place to further consolidate the types of
systems that are operational within the IT environment?
- Does the organization’s security philosophy support central security administration and
management, or is a decentralized approach preferred?
• System Use Considerations
– Who and what will use the system, and when, where, and why will the system be used? For
example:
- Who are the end users of the system (novice or expert user, employee or non-employee, etc.)?
- From where will users be accessing the system (home, office, company network, within the country
or across country borders, etc.)?
- When will users be accessing the system?
166 | P a g e
• Technical Environment/Architecture
– Characterization of the current IT infrastructure that will either help or impede security.
• Current Enterprise Security Architecture
- The current and future direction of the organization relative to security. For example, a common
enterprise security architecture goal is to externalize the user authentication processing from
applications to enable easier administration of user rights and privileges across multiple systems.
Thus, the system architecture team needs to consider if and how this should be accomplished for
the system level security architecture. Further, many organizations are establishing a set of
infrastructure security services – PKI, or proxies – that the system architecture team may want to –
or be forced to – take advantage of.
These second-order discussions need to include mid-level business management as well as the
applications development, IT infrastructure and security teams.
The system-level security architecture will flow out of these second-order discussions, and should
include the specific prioritized goals and requirements of the architecture. At this level, the output
will likely include an initial top-level design, and also should include non-technical process and
procedural controls (often identified in a Concept of Operation (CONOP)).
Walkthrough Bench Test
A best practice recommendation at this point in the architecture/design process is to go engage the
architecture and mid-level business management teams in a bench test -- sometimes referred to as a
walkthrough. The teams review the theory behind the system-level security architecture and top
level design. They apply a series of scenarios against the proposed architecture -- technical and nontechnical controls -- to see if they achieve the desired goals prior to moving onto the detailed design.
Of course, effective security also requires sound design, construction, testing, implementation,
maintenance and, in particular, training. In addition, since the new system will likely run across
existing infrastructure, the architecture team will necessarily have to consider whether the current
infrastructure provides adequate baseline controls for the new system. In our experience, many
organizations lack appropriate technical security standards and configuration procedures that serve
as the basis for a secure infrastructure. Like a house built on a shaky foundation, an application
hosted on a vulnerable infrastructure is at risk. Thus, you must also include architectural
requirements for the associated infrastructure, even for a system-level security architecture focused
on a single application.
Baseline Best Practice Template for Internet Speed
One of the most precious business commodities in the new Internet world is speed. The ability to get
to market more quickly with a business system than a competitor – "time to market" -- can provide a
decided competitive advantage.
167 | P a g e
Thus, the notion that "speed matters" is very appropriate to the new Internet business models.
However, the traditional architecture and design process can be a lengthy one, with cycle times that
are longer than many Internet business endeavours can endure. Therefore, many best practice
organizations adopt new architecture development process models that improve their ability to
quickly deploy new system-level architectures in general and system-level security architecture
specifically. We recommend the use of best-practice base line templates. Figure 8 shows how an
organization can develop and use baseline best-practice architectures to speed up the process.
The premise of this approach is that there are a relatively small number of different types of Web
based systems. Further, similar types of business systems share a set of similar information
protection requirements. These requirements can be enumerated and captured as a predefined set
of "best practice" system-level security architecture/design templates.
Thus, when business units decide to develop a new business system, the first hurdle for the security
team is to decide what "type" of business system it will be, and to choose the template that it most
closely matches. Then the first-order and even the second-order discussions can be focused on
where the new business application diverges from the baseline template -- this delta is often called
the GAP in consulting circles. The first facilitated discussions focus on the gap between the typical
security goals, threats, assets, vulnerabilities, etc. captured in the template, and the unique
requirements of the application at hand. Similarly, the secondary set of discussions would use this
gap information to provide the basis for a rapid development of a new system-level security
architecture/design.
To use a homebuilding analogy again, this process is similar to the use of model homes. Homebuyers
can pick a style, customize just a few components, and move into their development tract in no
time.
Using baseline best practices also helps you achieve the legal or regulatory standard of due care in
protecting company-owned assets, and assets in which the company plays a custodial role. By
benchmarking the baseline templates against the industry and continuing to evolve them to meet
best practice, the organization is taking prudent and responsible steps, which are typically part of
the due care considerations that regulators and courts review.
Finally, do not forget to appropriately size the infrastructure to meet the overall performance goals
of your applications. Performance is especially important when dealing with an Internet
environment. User calls to Web servers usually place a great load on the system. Turning on the
security features, for example, the logging services, will negatively affect system performance by
taking up a lot of system cycles. Encryption services for securing data transmitted over the Web are
notorious for being resource hogs. The underlying hardware infrastructure may not have been
adequately sized in order to take security programs into account.
168 | P a g e
Architecture and Design Tasks
We now again pick up the discussion of key architecture and design tasks. The following tasks are
discussed:
• Create System-Level Security Architecture
• Perform Architecture Walkthrough
• Create System-Level Security Design
• Perform Design Review
• Educate Development Teams on How to Create a Secure System
• Design End-User Training Awareness Measures
• Design a Security Test Plan
• Assess and Document How to Mitigate Key Application and Infrastructure Vulnerabilities
Execute enterprise and ICT system or application security policies
Procedures should contain sufficient detail to be executable25
Many organizations have those one or two superstar tech geniuses who know how to do everything.
While it is good to have such talent on your staff, it ultimately represents a risk to your organization
if security procedures are not put in place. What would be the response if your superstar is out on
vacation when his or her knowledge of how to do something is suddenly needed? Avoid such
circumstances by developing security procedures to define the how, where and when things get
accomplished. Beware to avoid developing procedures that rely on expert knowledge as a
foundation to execute the procedure, doing so often results in gaps in the procedure. A good test for
the level of detail for your procedure is to have some of your more junior staff execute the
procedure. If they can do it cleanly, then there is likely sufficient detail to your procedure. If not,
provide additional detail to your procedure. Also, make sure everyone who may execute the
procedure has the proper access/permissions.
The terms "policies and procedures" sound bureaucratic and, to many, is out of place in the dynamic
world of information technology. IT departments are constantly tasked with adapting to new
requirements, responding to changing business environments, and meeting aggressive project
schedules. It is not uncommon to hear complaints about formal policies and procedures slowing
things down—and sometimes they do, but that is not necessarily a bad thing.
25
Source: Linford & Co., as at https://linfordco.com/blog/security-procedures-building-on-the-foundation-ofsecurity-policy/, as on 9th May, 2017.
169 | P a g e
Policies and procedures define standards and methods for accomplishing specific tasks. In contrast,
ad hoc methods tend to "re-invent the wheel," depend upon undocumented practices, and often
leave systems more difficult to maintain than they should be26.
Policies are statements of objectives and direction that guide implementations. For example, an
organization might have a policy that all sensitive data that leaves the internal network should be
strongly encrypted. Procedures are step-by-step instructions for implementing a policy. In the
example just mentioned, a procedure for encrypting sensitive information on mobile devices might
include the installation of a program that automatically encrypts all data stored on the devices longterm storage mechanism. From an information asset protection perspective, several policies should
be defined, including those that define:











Acceptable use—Who is allowed to use the organization's information systems? For what
purpose? Under what conditions?
Access control standards—How are users authenticated to systems? What are password
standards? How are users assigned to security roles? Who has authority to change access
privileges?
Anti-malware practices—What anti-malware software should be used? How frequently
should full scans be performed? How frequently should devices check for updates? Who is
responsible for responding if a malware attack is detected?
Audit and vulnerability assessment procedures—What topics should be examined in an
information security audit? How frequently should they be conducted? How should
vulnerability assessments be performed? How should detected problems be remediated?
Client device security—What security programs must run on client devices? What
specialized restrictions apply to notebooks, PDAs, smart phones, and other mobile devices?
What privileges are users granted to modify their local machines? Is the use of USB memory
devices allowed?
Email use and retention policies—What is the acceptable use of email systems? How should
incoming and outgoing email be scanned? What are quarantine procedures for potentially
malicious code or inappropriate content?
Encryption use—When should encryption be used? What algorithms and key lengths should
be used? How should keys be stored and distributed?
Information privacy—What information is considered private, confidential, or sensitive?
What are the rules for disclosing such information? In what situations should personally
identifying information, such as Social Security numbers, be collected? What regulations and
corporate governance policies apply to privacy protections in information systems?
Risk analysis—How should information assets be valued? What are the organization's levels
of risk tolerance?
Server security—How should servers be locked down? What OS services should be allowed
to execute? What restrictions are applied to servers that are accessible directly from the
Internet, for example, those in a DMZ?
Wireless security—Under what conditions are wireless access points deployed? Which
wireless security protocols will be used? How will rogue devices be detected?
26
Source: Tech Target, as at http://searchsecurity.techtarget.com/feature/Developing-and-MaintainingPolicies, as on 9th May, 2017.
170 | P a g e
It might be difficult o develop polices for all of these areas immediately. Start with the acceptable
use policy, access control standards, anti-malware, and information privacy area. If wireless devices
are used in your organization, develop a wireless security policy as soon as possible. As with any
aspect of security, you must prioritize based on the needs of your organization. There are other
areas that warrant formal policies—for example, when virtual private networks (VPNs) are used,
when third parties are granted access to key applications, and when procuring IT assets. Policies
serve a unifying purpose by describing what is to be accomplished; this is especially important when
multipoint solutions are deployed.
Company security policies are designed to create a safe workplace for employees and
management. In 2009, there were approximately 572,000 instances of workplace crime such as
assault and robbery committed in the United States, according to the U.S. Department of Justice
website. Company management develops security policies, but employees have responsibilities
toward those policies to maintain a safe and effective workplace27.
Comprehension
Management develops workplace security policies and training programs to familiarize employees
with the ways to maintain a safe workplace. But management cannot force employees to
understand all of the policies. It is the responsibility of employees to benefit from workplace
security training and to come away with a comprehensive understanding of policies. If an
employee does not understand a policy, or did not get information on a security measure, she
must approach management to get clarification or more information.
Vigilance
Employees need to remain vigilant when it comes to executing security policies in the workplace.
When an employee sees suspicious activity, he needs to follow security procedures and report it.
A workplace security policy is effective only if it is used and practiced. Employees should make it a
point to attend all security training classes and to be ready to use security procedures at all times.
Personal Space
Part of employee responsibility in maintaining a company security policy is being responsible for
his own area. Employees need to make sure that their work areas adhere to security standards,
and each employee must be certain that her personal effects in the work area do not hamper
security. For example, if an employee has a large plant on top of his file cabinet that blocks a
security camera, that plant needs to be moved.
27
Source: Chron, as at http://smallbusiness.chron.com/employees-responsibilities-maintain-security-policy12087.html, as on 9th May, 2017.
171 | P a g e
Procedures
Employees need to have respect for corporate security procedures to allow those procedures to
be effective. For example, an employee should refuse to assist a co-worker in bypassing the cardswiping entry system because the co-worker forgot her access card. The employee should remind
the co-worker of the security procedure in place for people who misplace their access cards.
Application security has become a critical issue for large and midsize organizations. From high-profile
data theft associated with Web applications to compliance requirements that impact applications of
all shapes and sizes, securing your applications demands constant vigilance. Not only are the costs of
security failures high, but so are the costs related to identifying defects and fixing vulnerabilities28.
As the risks and consequences of security breaches continue to rise, comprehensive security
protection can no longer be considered an afterthought, it must be built into every phase of your
development life cycle. With so many security solutions available, enterprises like yours need to
identify solutions that offer the most effective blend of capabilities and functionality to help reduce
risks and overall costs. When evaluating application security and risk management solutions,
however, you might find yourself confronted with vague product benefit statements and seemingly
favorable pricing offers driven by vendors who want to steer purchasing decisions to their specific
solutions.
How can you increase your organization’s leverage and make an educated decision? By carefully
evaluating vendors against the key capabilities listed below, which typically characterize best-in-class
security and risk management solutions. Decision makers in your organization will be able to select
solutions that reduce security risk while simultaneously lowering the cost of addressing
vulnerabilities. Your ultimate goal should be an integrated, end-to-end life cycle approach to security
and risk management.
Your Vendor Selection Checklist
Does the vendor your organization is considering provide:





Comprehensive, advanced security testing and risk management technologies that permit
you to identify areas of highest potential risk so that you can target those risks for future
remediation?
Broad coverage of current Web-based and mobile application security technologies?
Comprehensive security program management capabilities, which can be applied to your
entire application development life cycle?
Testing support for the large and diverse volume of applications that are currently deployed
by your organization or are slated for future deployment?
Policies, reporting and work flow tools for security governance and risk management?
28
Source: Security Intelligence, as at https://securityintelligence.com/best-application-security-riskmanagement-solutions/, as on 9th May, 2017.
172 | P a g e

A broad and diverse portfolio of security solutions that can be deployed in conjunction with
security testing technology to improve your overall security protection and reduce overall
risk?
Once a set of solutions is evaluated against these criteria, you are bound to find a wide disparity
between limited, one-size-fits-all security offerings and superior solutions that offer integrated, endto-end life cycle approaches to application security and risk management.
Benefits of Early Application Security Testing
In our “IBM X-Force Threat Intelligence Quarterly – Q1 2014” report, we documented 8,330 security
vulnerability disclosures in 2013, an increase of more than 1,000 disclosures since 2011. Of those
vulnerabilities, roughly a third of them were targeted at Web applications. In its “2013 Cost of Data
Breach Study: United States,” the Ponemon Institute estimated that data breaches cost companies
an average of $188 per compromised record in 2012; major data breaches could easily end up
costing your organization hundreds of thousands — if not millions — of dollars.
Countless security studies highlight the brutal fact that nearly every Web application contains
vulnerabilities. If these vulnerabilities are not addressed proactively and result in a loss of customer
data, your organization is likely to face costly lawsuits, damage to your brand image and an erosion
of customer trust.
Not only are the costs of responding to such security incidents high, but the costs of identifying and
fixing application defects that result in data breaches are also expensive in the first place. To
maintain software release schedules, many organizations conduct security testing after their
software exits the system testing/quality assurance (Q/A) phase. In fact, many defects aren’t even
identified until applications reach production phase. The cumulative financial impact of such latestage testing can be enormous. The National Institute of Standards and Technology (NIST) calculates
that the cost of correcting a software error in the post-product release phase is approximately 30
times the cost of addressing the same issue during the coding phase of development.
It’s clear that the risks and consequences of security breaches continue to rise and that
comprehensive security protection can no longer be considered an afterthought. Rather, security
protection must be built into every phase of your development life cycle and also into your Q/A
process.
Making Your Case for an Integrated, End-to-End Life Cycle Approach
With a wide range of application security solutions available, organizations need to weigh the
relative benefits of each potential solution while also evaluating potential costs. For most
organizations, an integrated, end-to-end life cycle approach to securing applications produces the
best outcome.
However, many organizations still utilize a variety of point solutions to conduct security analysis,
many of which are expensive to purchase and/or maintain and fail to provide comprehensive
security testing.
173 | P a g e
Often, point solutions offer primitive security governance processes that are limited in scope or
require manual user intervention, limiting your ability to increase organizational efficiency and
reduce costs.
But the benefits of comprehensive security and risk management solutions are compelling. Mediumand large-sized organizations that leverage best-in-class application security and risk management
tools are able to:




Locate more vulnerabilities. By utilizing a comprehensive set of security testing tools that
can be deployed at each stage of development, software development teams aren’t left
guessing about testing coverage.
Accelerate discovery and tracking of security vulnerabilities. The more comprehensive the
deployment of security testing procedures, the earlier the procedures can be applied in your
software development life cycle. Consequently, vulnerability detection is promoted to an
earlier stage of your development life cycle.
Reduce the cost of fixing security vulnerabilities. Moving remediation to an earlier point in
the software development life cycle will save your organization time and money. As noted
earlier, fixing a security issue in the coding stage results in much lower costs than eliminating
it during the post-product release phase.
Reduce the cost of implementing security governance and risk management best practices.
Built-in work flow and tools to support large-scale application security testing, manage
security issues that are identified, reduce security risk, track compliance and integrate
security intelligence analysis into the development life cycle are all essential components of
effective application security management programs. The solution you choose should
reduce your expenses while increasing efficiency. Furthermore, when developers see clear
links between risks and the code that results from those risks, they can focus on building
secure applications rather than spending an inordinate amount of time determining where
risks might exist in the code base.
Activity 7
Who is responsible for Execution of enterprise and ICT system or application security policies on
a typical organisation?
174 | P a g e
Activity 7
175 | P a g e
Activity 7
Create System-Level Security Architecture
Key subtasks follow for the task, Create System-Level Security Architecture. Identify Technical
Security Controls
At this point, the task is to develop a list of the technical security controls that trace back to the
prioritized security goals and requirements. These include technical control methods such as:
• Network, and application access controls
• Authentication requirements
• Encryption
• Redundancy
• System hardening (configuration) procedures
• Etc.
Identify Non-Technical Security Controls
Similarly, the task here is to identify a list of non-technical controls that trace back to the previously
determined security goals and requirements. They include items such as:
• Multiple-signatures
• Separation of duties/functions
• Etc.
176 | P a g e
Other important tasks in the architecture and design phase follow. Perform Architecture
Walkthrough
At this stage, the key is to review the proposed technical & non-technical controls to ensure they
accomplish the security goals.
Create System-Level Security Design
The design process will likely be an iterative process that will start with more basic lists and be
enhanced to provide additional specificity. In the top-level design the tools, services, sub-systems,
etc. that will provide the technical security controls are more fully detailed. This would include
detailed security tools/service lists, top-level network diagrams, data flow diagrams, object lists, etc.
On the nontechnical side specific processes/procedures are listed and top-level process integration
diagrams are created in the CONOP (detailed below). The processes/procedures are detailed in
subsequent steps.
Top-Level Non-Technical Security Design – Concept of Operations (CONOP) A Security Concept of
Operations (CONOP) is a high-level outline of security-related processes and procedures.
Its common processes and procedures break down into the following categories:
• Core Information Security Processes -- Address the most critical aspects of security, and are
typically created, owned, maintained, and performed by the security organization, or a matrix team
with security responsibility. Processes are usually of long duration (days, weeks, months) or ongoing
in nature.
• Core Information Security Procedures -- Typically created and refined by the security organization,
or a matrix team with security responsibility. Procedures are typically of short duration (a few
minutes or days).
• Information Technology (IT) Processes -- Typically managed by various IT departments, but require
some level of integration with security processes and procedures.
• Business Processes -- Maintained outside of the IT department, and require integration with
various Information Security processes or procedures.
Apply and verify compliance with identified standards against which to
engineer the ICT system or application
A systems development life cycle is composed of a number of clearly defined and distinct work
phases which are used by systems engineers and systems developers to plan for, design, build, test,
and deliver information systems.
177 | P a g e
Like anything that is manufactured on an assembly line, an SDLC aims to produce high-quality
systems that meet or exceed customer expectations, based on customer requirements, by delivering
systems which move through each clearly defined phase, within scheduled time frames and cost
estimates. Computer systems are complex and often (especially with the recent rise of serviceoriented architecture) link multiple traditional systems potentially supplied by different software
vendors. To manage this level of complexity, a number of SDLC models or methodologies have been
created, such as "waterfall"; "spiral"; "Agile software development"; "rapid prototyping";
"incremental"; and "synchronize and stabilize"29.
SDLC can be described along a spectrum of agile to iterative to sequential methodologies. Agile
methodologies, such as XP and Scrum, focus on lightweight processes which allow for rapid changes
(without necessarily following the pattern of SDLC approach) along the development cycle. Iterative
methodologies, such as Rational Unified Process and dynamic systems development method, focus
on limited project scope and expanding or improving products by multiple iterations. Sequential or
big-design-up-front (BDUF) models, such as waterfall, focus on complete and correct planning to
guide large projects and risks to successful and predictable results. Other models, such as
anamorphic development, tend to focus on a form of development that is guided by project scope
and adaptive iterations of feature development.
In project management, a project can be defined both with a project life cycle (PLC) and an SDLC,
during which slightly different activities occur. According to Taylor (2004), "the project life cycle
encompasses all the activities of the project, while the systems development life cycle focuses on
realizing the product requirements".
SDLC is used during the development of an IT project, it describes the different stages involved in the
project from the drawing board, through the completion of the project.
The SDLC isn't a methodology per se, but rather a description of the phases in the life cycle of a
software application. These phases (broadly speaking) are, investigation, analysis, design, build, test,
implement, and maintenance and support. All software development methodologies (such as the
more commonly known waterfall and scrum methodologies) follow the SDLC phases but the method
of doing that varies vastly between methodologies. In the Scrum methodology, for example, one
could say a single user story goes through the all the phases of the SDLC within a single 2 week
sprint. Contrast this to the waterfall methodology, as another example, where every business
requirement (recorded in the analysis phase of the SDLC in a document called the Business
Requirements Specification) is translated into feature/functional descriptions (recorded in the design
phase in a document called the Functional Specification) which are then all built in one go as a
collection of solution features typically over a period of three to nine months, or more. These
methodologies are obviously quite different approaches yet, they both contain the SDLC phases in
which a requirement is born, then travels through the life cycle phases ending in the final phase of
maintenance and support, after-which (typically) the whole life cycle starts again for a subsequent
version of the software application.
29
Source: Wikipedia, as at https://en.wikipedia.org/wiki/Systems_development_life_cycle, as on 9th May,
2017.
178 | P a g e
Phases
The system development life cycle framework provides a sequence of activities for system designers
and developers to follow. It consists of a set of steps or phases in which each phase of the SDLC uses
the results of the previous one.
The SDLC adheres to important phases that are essential for developers, such as planning, analysis,
design, and implementation, and are explained in the section below. It includes evaluation of
present system, information gathering, feasibility study and request approval. A number of SDLC
models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental,
synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a
sequence of stages in which the output of each stage becomes the input for the next. These stages
can be characterized and divided up in different ways, including the following:

Preliminary analysis: The objective of phase 1 is to conduct a preliminary analysis, propose
alternative solutions, describe costs and benefits and submit a preliminary plan with
recommendations.
1. Conduct the preliminary analysis: in this step, you need to find out the organization's
objectives and the nature and scope of the problem under study. Even if a problem
refers only to a small segment of the organization itself, you need to find out what
the objectives of the organization itself are. Then you need to see how the problem
being studied fits in with them.
2. Propose alternative solutions: In digging into the organization's objectives and
specific problems, you may have already covered some solutions. Alternate
proposals may come from interviewing employees, clients, suppliers, and/or
consultants. You can also study what competitors are doing. With this data, you will
have three choices: leave the system as is, improve it, or develop a new system.
3. Describe the costs and benefits.

Systems analysis, requirements definition: Defines project goals into defined functions and
operation of the intended application. It is the process of gathering and interpreting facts,
diagnosing problems and recommending improvements to the system. Analyzes end-user
information needs and also removes any inconsistencies and incompleteness in these
requirements.
A series of steps followed by the developer are:
1. Collection of Facts: End user requirements are obtained through documentation,
client interviews, observation and questionnaires,
2. Scrutiny of the existing system: Identify pros and cons of the current system inplace, so as to carry forward the pros and avoid the cons in the new system.
3. Analyzing the proposed system: Solutions to the shortcomings in step two are found
and any specific user proposals are used to prepare the specifications.

Systems design: Describes desired features and operations in detail, including screen
layouts, business rules, process diagrams, pseudocode and other documentation.
179 | P a g e






Development: The real code is written here.
Integration and testing: Brings all the pieces together into a special testing environment,
then checks for errors, bugs and interoperability.
Acceptance, installation, deployment: The final stage of initial development, where the
software is put into production and runs actual business.
Maintenance: During the maintenance stage of the SDLC, the system is assessed to ensure it
does not become obsolete. This is also where changes are made to initial software. It
involves continuous evaluation of the system in terms of its performance.
Evaluation: Some companies do not view this as an official stage of the SDLC, while others
consider it to be an extension of the maintenance stage, and may be referred to in some
circles as post-implementation review. This is where the system that was developed, as well
as the entire process, is evaluated. Some of the questions that need to be answered include:
does the newly implemented system meet the initial business requirements and objectives?
Is the system reliable and fault-tolerant? Does the system function according to the
approved functional requirements? In addition to evaluating the software that was released,
it is important to assess the effectiveness of the development process. If there are any
aspects of the entire process, or certain stages, that management is not satisfied with, this is
the time to improve. Evaluation and assessment is a difficult issue. However, the company
must reflect on the process and address weaknesses.
Disposal: In this phase, plans are developed for discarding system information, hardware
and software in making the transition to a new system. The purpose here is to properly
move, archive, discard or destroy information, hardware and software that is being
replaced, in a manner that prevents any possibility of unauthorized disclosure of sensitive
data. The disposal activities ensure proper migration to a new system. Particular emphasis is
given to proper preservation and archival of data processed by the previous system. All of
this should be done in accordance with the organization's security requirements.
In the following example (see picture) these stages of the systems development life cycle are divided
in ten steps from definition to creation and modification of IT work products:
180 | P a g e
The tenth phase occurs when the system is disposed of and the task performed is either eliminated
or transferred to other systems.
Not every project will require that the phases be sequentially executed. However, the phases are
interdependent. Depending upon the size and complexity of the project, phases may be combined or
may overlap.
Activity 8
Describe the actions that could be taken if it is determined that the ICT system does not meet
required compliance standards.
181 | P a g e
Activity 8
182 | P a g e
Activity 8
183 | P a g e
Activity 8
Perform processes and procedures to mitigate the introduction of
vulnerabilities during the engineering process
Implementation Phase –
– Inspection and Acceptance – ensures that the organization validates and verifies that the
functionality described in the specification is included in the deliverables.
– Security Control Integration – ensures that security controls are integrated at the operational
site where the information system is to be deployed for operation. Security control settings and
switches are enabled in accordance with vendor instructions and available security
implementation guidance.
– Security Certification – ensures that the controls are effectively implemented through
established verification techniques and procedures and gives organization officials confidence that
the appropriate safeguards and countermeasures are in place to protect the organization’s
information system. Security certification also uncovers and describes the known vulnerabilities in
the information system.
– Security Accreditation – provides the necessary security authorization of an information system
to process, store, or transmit information that is required. This authorization is granted by a
senior organization official and is based on the verified effectiveness of security controls to some
agreed
upon level of assurance and an identified residual risk to agency assets or operations.
184 | P a g e
Why is Security Testing in the SDLC important?30
Security testing is one of the most important aspects of any Secure SDLC approach.
Why? For one, security testing in the SDLC identifies security issues that need to be addressed. The
sooner you can find them, the more money you save: fixing security issues, like any bugs, gets more
expensive the later in the lifecycle you find them. Waiting until later stages of the SDLC to begin
security testing leads to hasty fixes in order to stay on schedule will not bode well when customers
complain – or worse.
And that’s not even considering the kinds of costs we’ve seen organizations pay when they don’t
discover a vulnerability at all. Breaches are costly, and the ROI gained from proper implementation
of security testing in the SDLC is proven by avoiding just one security breach.
Secondly, the various types of tests you’ll perform throughout the lifecycle will also let you know
how closely the security architecture and design is being followed. In essence, security testing is a
barometer of security quality within your SDLC, as well as the best way to develop and maintain
applications efficiently and in line with organizational needs and risks.
30
Source: Checkmarx, as at https://www.checkmarx.com/2016/02/26/security-testing-sdlc-beginners-guide/,
as on 10th May, 2017.
185 | P a g e
Lastly, but perhaps most importantly, security testing gives an organization a strategic approach to
improving security in their application portfolio, and is a business imperative for any business trying
to minimize the potential risks – including compliance requirements – that application security
vulnerabilities can pose.
Where Does Security Testing Fit in the SDLC?
Security testing can be done through much of the SDLC, as early as during the analysis and design
phases, as well as throughout development and, of course, during the testing phase. And just
because an application is released, doesn’t mean you can stop thinking about the application – but
we’re focusing on testing done during the lifecycle for now.
The security testing strategy, as we discuss below, needs to be based on your individual
organizational structure and what the established SDLC process allows for. Typically, however,
security testing can be broken up into three areas during the SDLC:

Requirements and Analysis Phase
During this phase, as security requirements are mapped out, testing plans can be created to better
track the completion and success of the stated requirements.

Development Phase
186 | P a g e
As soon as code is being written, static application security testing can begin. Starting testing as soon
as your SDLC allows facilitates the best way to stop vulnerabilities from making their way to the
finished product. With partial code scanning, source code can be scanned at any point in time during
the build, making vulnerability discovery that much faster and more effective.

Code Reviews & Manual Testing Phase
Finally, once development is finished, a final secure code review along with manual testing can help
detect logical code flaws and ensure that issues found during the development phase have been
fixed correctly and new vulnerabilities have not been introduced.
Defence in depth is a key aspect to a successful application security program – and the same goes for
security testing in the SDLC.
4 Key Steps to Security Testing in the SDLC:
1. Make it measurable
As the OWASP Testing Guide so rightly says in the introduction, “you can’t control what you can’t
measure.” Security testing is no different – especially when first implementing it within the SDLC.
Being able to look through your testing history and comparing it over time is essential in seeing (and
reporting up) on improvement. In order to do so, begin by establishing goals and metrics from the
get-go, working with stakeholders – from the board to developers – to set expectations and gather
feedback on the processes themselves.
2. Ensure testing tools are easy to adopt
Making sure the tools you choose are chosen in terms of learning curve and adoption rate by
developers are important factors in whether or not your security testing program will be successful
or not. Many developers haven’t dealt with needing to test for security before, so if a tool is difficult
to use or well-integrated into the developer’s current toolset, chances are it’s not going to get used.
Don’t spend a fortune on the “best tool in the business” if it’s not likely to be used by those that
would be in the business of using it.
3. Automate wherever possible
If you’re doing a good job of training your developers, you want to make sure they’re spending the
most time doing what they were hired and trained to do – code securely.
Instead of burdening them with long hours of code review or manual security testing at each
milestone, you can automate at least parts of that process with source code analysis tools,
implemented into their IDE. At check-in, developers can simply scan their code and get quick results
back instantly, allowing them to fix the code while it’s still fresh in their minds.
4. Align security testing activities to your current SDLC process
187 | P a g e
The phases you’ll be able to integrate security testing into and how quickly security testing can be
introduced largely depends on the existing SDLC process in place in your organization. In agile
environments, for instance, security testing can and should be integrated as early as possible, while
in waterfall environments, security testing may not be possible until development is well-underway.
While security testing should always be integrated as early as possible, it’s more important to make
sure security is a business enabler by working with the current processes – not against them.
Perform secure configuration management practices
Operations / Maintenance Phase –
– Configuration Management and Control – ensures adequate consideration of the potential
security impacts due to specific changes to an information system or its surrounding environment.
Configuration management and configuration control procedures are critical to establishing an
initial baseline of hardware, software, and firmware components for the information system and
subsequently controlling and maintaining an accurate inventory of any changes to the system.
– Continuous Monitoring – ensures that controls continue to be effective in their application
through periodic testing and evaluation. Security control monitoring (i.e., verifying the continued
effectiveness of those controls over time) and reporting the security status of the information
system to appropriate agency officials is an essential activity of a comprehensive information
security program.
When you think of configuration management, what is the first thing that springs in your head?
Usually when I ask people this question, I generally receive an answer along the lines of software
development, or some type of engineering deliverable31.
Traditionally, configuration management has its roots in the manufacturing and software
development arenas; something that is an actual deliverable. Configuration management follows a
linear path, similar to project management, and revolves around the control and release of different
product versions. Until recently, security was not on the radar of configuration management
professionals with the exception of the physical security.
However, for the past few years configuration (sometimes also referred as Change Management)
has been finally gaining ground as a discipline that is in demand in the security world. Right now it is
in its infant stages as vendors, and security professionals attempt to categorize or better define the
role of configuration management in the security discipline. Depending on who you talk to
configuration management can mean different things, it can mean how your network devices are
configured, or it can mean what version of the application you are running, it could mean what was
the last patch installed on your device., or the baselines hardware and applications that run on your
devices.
Ask yourself, what does configuration management mean to you? Does it strictly revolve around
31
Source: SANS, as at https://www.sans.edu/cyber-research/security-laboratory/article/meyer-configmanage, as on 10th May, 2017.
188 | P a g e
CMM, or CMII? Does it involve an administrative only process such as a CCB? Now ask yourself who
is the configuration management professional in your organization? Now ask yourself is this person
also a security professional? If not they should be, and if you don’t have yourself a configuration
management professional you better get one into your security department, and here’s why.
Configuration management drives information security and information assurance. It’s in everything
and is imbedded everywhere, but few people acknowledge this fact, and your organization may be
suffering because of it. It’s how you manage your infrastructure, its how you manage your
information security program, its how you build and manage your information security process.
Every security professional should have some type of configuration management skills in their tool
box, along with everything else. It’s pointless to buy the best firewall on the market, and not have a
good SOP to maintain its configuration so only authorized traffic crosses it. You should think of
configuration management kind of like the tumbler within the lock on the front door of your home.
You could buy a steel door, and put a tank of a lock on it to keep everyone out, but if you don’t
configure the tumblers within the lock, anyone can get in and all of that time and effort is wasted.
Lack of configuration management puts additional risk to your environment. The diagram below
shows the many areas that configuration management resides within your security program.
As a rule of thumb, configuration management can be broken down into three distinctive disciplines
for your environment, with all three of them having different requirements, process and tools. The
three disciplines are:
1. Business Process Infrastructure (Chain of Command, CCB)
2. Operations and Services (Operational Group)
3. End Products (technical group)
The Business Process Infrastructure weather you are federal government or commercial sector is the
backbone for the rest of the organization. The business process is where the rules and
responsibilities are identified, policy is written and accepted, and more importantly it is where the
process is built in order to successfully manage the security posture of your organization. Your
business process infrastructure is where your authority originates, and the correct people are given
the correct level of authority and executive buy in order to make change with the organization as the
security threat changes. Your business process infrastructure needs to be built with the mindset of
accommodating change. Unfortunately, many organizations do not allow for enough flexibility in
their change process that allows for rapid reconfiguration requirements, which are necessary in the
security environment. Many configuration management professionals either put too little effort into
accommodating change, or put too much effort in locking down the change with excess efforts
making change difficult.
Examples of these deficiencies in proper business process infrastructure were the past Veterans
Department data loss. Many security best practices where not enacted due to the executive
leadership not giving the proper personnel the correct level of authority necessary in order to enact
change. Additionally, the Navy set its business process infrastructure into a bottleneck in order to
attempt to get a handle on their information Assurance efforts.
Accommodating changes was not taken into consideration as a single point of failure was created
which significantly reduce process flow.
189 | P a g e
Configuration management plays a role in these efforts because the Configuration Management
professionals should be the facilitators of this process. They are not the process owners, rather than
the process facilitators. Configuration management owns the document creation, revisions, releases,
and process improvement activities for the business process infrastructure, and influences best
practices. A configuration management professional should be knowledgeable enough in security
and information assurance in order to begin process improvement utilizing security best practices in
the dosing of organization business process.
Once the security business process infrastructure framework is designed, documented, accepted and
put under configuration control, the next area of concern is the configuration, and change controls
of enterprise services and operations. This is completed by developing and taking configuration
requirements operational. This also is a critical step in the building of the secure infrastructure, and
is the meat and potatoes of providing a defense in depth to your organization. The authority is
driven by the acceptance of the business process infrastructure, however, the operational needs,
wants, and the protection profiles requirements to meet the need, and want requirements are
developed within this operation framework. Configuration management again is the process
facilitator, the CM professional needs to ensure their process flows take all operational services
provided by the organization, can accommodate change within it from cradle to grave. A possible
framework is displayed in the following figure.
This is a typical operational framework under configuration control for active management. The CM
professional generally does not fill the role of making the sole decisions of the baseline configuration
requirements for each domain within the framework, but is an active team member in the creation
of the baseline standards. The CM role should be the primary facilitator of change to baseline
framework, and ensure that the As-Built infrastructure is current in real time. The CM professional
should be able to manage three different levels of enterprise architecture utilizing security best
practices, the As-Built, the To-Be, and the As-Planned.
190 | P a g e
Each area of focus has distinct security affects for the enterprise. The As-built is the real time
operation of the enclave in real time directly supporting the mission of the organization. This is
where the change management process controls what is built into the infrastructure, what data
transverses the infrastructure and what is decommissioned from the infrastructure.
The To-Be environment is the next generation of the infrastructure that is needed to support the
every fluid environment of today’s rapid reconfiguration requirements. The To-Be environment
represents the near future architecture and protection profiles needed to sustain operations. This is
where configuration management plays a large role within the enterprise architecture discipline. The
CM professional should know everything about an organizations As-Built so that decision makers are
armed with the correct data to make educated decisions about their architecture. Generally the ToBe is at a stage where actual hardware and software needs have been identified in detail, integration
testing has been completed. The To-Be environment is where Information Systems Security
Engineering (ISSE) process is at their best.
The As-Planned environment is the long term view of the organizations enclave. The As-Planned is
generally high level architecture for propos3ed future needs wants. All needs start in the As-Planned
stage of the life cycle, where they are more finally tuned to meet stricter and more defined
requirements as they progress from the As-Planned to the To-Be, and finally into the As-Built. This is
all facilitated by configuration management.
The COOP area of the framework again is not the sole property of configuration management but
again they are a critical team member in the development of it. The CM professional should be able
to assist any security professional with critical data required in order to effectively build the COOP
elements. Configuration Management should know where assets are, what they are, what they are
doing, and who they were doing it with. This gives security personnel which solid data to better
assess backup strategies, critical devices, disaster recover prioritization, and business impact
analysis. Generally document library control falls under the configuration management group for
quality assurance, for which ISO 900 series is popular. As device, data flow, and capabilities are
added and decommissioned from each environment, the COOP documentation needs to be
consistently revised and released in order to capture the impact of the change.
Typical security practices are overlooked, since accommodating change is not front loaded into the
environment, changes to the environment are not captured in the latest revision of the COOP, this in
turn can be catastrophic in the event of an incident. The CONOPS is where the operation
configurations requirements and processes reside. For the DOD the DIACAP Knowledge Service is a
good example of where a CONOPS policy and process can be drafted from. The DIACAP Knowledge
service controls are under DIACAP TAG configuration control. As threats change, the controls can be
changed to assist in mitigating the threat. Configuration Management should maintain this
operations document to reflect the current controls posture, setting the baseline for user
operations. The CONOPS should outlines policy, and process required in order to fulfill the daily
duties of the organization such as the firewall change process, Access controls levels, user roles, and
responsibilities. The CONOPS is a living document that changes as the current threat changes in
regards to normal operations. The CONOPS is an operational baseline and should also fall under
configuration control.
191 | P a g e
The Audit domain in the framework is the checks and balances, as well as compliance area for the
environment. Regular audits should always be included into all process with the organization in
order to help maintain internal compliance. Audits not only provide a valuable metric in assessing
your security posture overall, but it also provides a number of security improvement.


Organizational Compliance - Compliance does not result in good security, but good security
does result in compliance, therefore, weather you are looking for FISMA or SOX type
compliance you should be well on your way because you are a security practitioner, by being
proactive, and not reactive.
Continuous Improvement - Audits allow the decision makers the ability to quantify if
processes are effective, this allow decision makers the ability to intervene as integrity
declines. The audit domain is the obvious; it is a method of checks and balances to maintain
the appropriate security posture.
End product configuration management is the management of the As-Built devices themselves, and
is generally where the current commercial tools venders are focusing on. This area of focus is also
the most technical of all of the areas, and if developed properly in conjunction with the other
configuration management areas is the most important. The end product configurations should be
designed in the To-Be domain for operation deployment. When a new need and want is identified in
the As-Planned architecture, then further analysis selects and actual product to perform that want,
the baseline configuration for that device should be assembled. The CM professional should be the
facilitator of this baseline, to maintain the security posture of the environment, by utilizing the
System development life cycle, in addition to the information systems security engineering
processes. This is where the CM professional Information Security engineer, and systems engineer
should converge and team, to establish as baseline, that:
1. Meets system requirements
2. Meets security requirements
3. Can be moved into the As-Built and integrate
Many times, these efforts are undertaken in different phases of system development, when in
actuality they must be undertaken in a teaming environment. This is the reason why a Project
Engineering Review Meeting (PERM) should be utilized. The purpose of the PERM is to take an AsPlanned requirement, and build a To-Be solution, for future transition into the AS-Built after
approval from the CCB. The PERM is the critical exchange of communications, and talent that is
generally missing from many organizations. Lack of a PERM type capability, is generally the sole
reason why project fail, to either meet requirements, meet security needs, which in turn results in
delays and cost overruns, in additional to putting additional risk to the infrastructure.
Configuration management is a growing discipline and can provide a solid backbone in order to
maintain secure operations. The role is growing, and continuous to influence the IT realm as more
and more capabilities with IT infrastructure. In order to practice true defense in depth, an identified
and accepted configuration management role needs to be introduced into the security operations.
192 | P a g e
Defence in Depth can now be viewed in three dimensional terms. As security services, such as
Cryptography, Firewalls, Intrusion detection and prevention are deployed, in addition to the CM
framework, and building these solution based on the differing levels of IT will provide a robust
security, operations, and compliance best practice.
Deployment/Implementation
This phase involves taking an application from the testing environment to the production
environment for limited (e.g., pilot) or full-production uses.
Simply put, you want to make sure the people carrying out the deployment follow the security
related processes and procedures that you set up in the preceding phases.
Deploy Training and Awareness Program
This task entails implementation of a security training and awareness program. Administrative
personnel and users should be schooled in the system's security functions.
Secure Configuration Management32
When considering secure configuration management, the biggest challenge may be simple
nomenclature— everyone calls this something different. SANS calls these controls “secure
configurations” for servers, workstations, and network and security devices. The National Security
Agency (NSA) calls the same thing “patch management” and “baseline management,” among other
things.
32
Source: SANS, as at https://www.sans.org/reading-room/whitepapers/analyst/secure-configurationmanagement-demystified-35205, as on 10th May, 2017.
193 | P a g e
The Payment Card Industry Data Security Standards (PCI DSS) compliance standard refers to
requirements for secure configurations such as “Do not use vendor-supplied defaults for system
passwords and other security parameters” and “Develop and maintain secure systems and
applications,” without explicitly using the terms “configuration management” or “secure
configuration.” In NIST 800-53 version 4, currently available as a draft for review, there is a general
category of security controls labelled “configuration management.”
Fundamentally, all of these terms refer to the same concepts and topics. Throughout this document
we call this process secure configuration management. What exactly is secure configuration
management? In a nutshell, secure configuration management is the technical application and
maintenance of security policy on systems, applications and network devices. There are several
distinct disciplines that exist within the realm of secure configuration management, including the
following:
Configuration Management Planning and Management
This aspect of configuration management is primarily concerned with developing the configuration
management plan, including who will manage it, what type of Configuration Management Database
(CMDB) will exist, and what types of tools and processes will be employed.
Configuration Identification
During the Configuration Identification stage, specific Configuration Items (CIs) are defined for
individual platforms. These are what will be implemented, measured and maintained over time. For
systems and network devices, these controls may be driven by compliance mandates such as the PCI
DSS and the Federal Information Security Management Act (FISMA), as well as National Institute of
Standards and Technology (NIST) documents (e.g., 800-53) and the Center for Internet Security (CIS)
and Defense Information Systems Agency (DISA) guides.
Configuration Control
CIs are implemented, organizations can deploy a monitoring system for the controls that focuses
primarily on change detection and serves as an holistic change management program. This stage is
implemented at two levels. The first application is within the overall CI database and the specific CIs
for systems. When a configuration template needs to be changed or updated, it should be
accommodated within the change management framework. The second way this phase is managed
is at a local level, where changes need to be monitored, implemented, and in some cases, rolled
back or remediated when the change is either unplanned or due to malicious activity.
Configuration Status Accounting
This configuration management process focuses on defining and documenting baseline
configurations and then maintaining the baselines over time.
Configuration Verification and Audit
194 | P a g e
Configurations for systems and network devices need to be audited and monitored, with detailed
reports prepared for comparison with existing and planned baselines. Performing such audits
continuously is best for maintaining adequate security, but regularly scheduled routine audits can
also be implemented.
Configuration Remediation
After configuration assessments are performed, there will usually be a variety of configuration items
that need to be corrected or changed in some way to meet policy and compliance specifications. IT
operations teams usually perform these changes with input from audit and IT security groups.
Remediation can be issued in the form of written guidance, as well as through more automated
scripts and workflows that are kicked off after change approval.
Challenges with Secure Configuration Management
In an InformationWeek survey of CISOs, “enforcing security policies” was ranked as the No. 2
“biggest security challenge,” and the biggest overall challenge was managing complexity.13
of security and compliance-related controls maintained by security and operations teams into the
following categories:
Physical Host Operating Systems
Physical servers and workstations make up the bulk of IT infrastructure. The operating platform that
runs on these physical systems has a number of distinct controls including access controls, operating
system tuning parameters and file-level controls for data storage.
Virtual Operating Platforms and Guest Operating Systems
As more organizations realize the cost savings and operational benefits of virtualizing systems, an
increasing amount of virtual technology will be deployed. In addition to traditional operating system
controls, these systems contain their own platform-specific code and virtual network infrastructure
that require controls to be applied. To that end, virtualization brings about an entirely new layer of
complexity, with a staggering array of new configuration items that should be evaluated and locked
down.
Applications and Databases
Applications and databases have their own specific sets of controls to maintain and monitor. Web
servers have access controls, file and directory permissions, as well as customized database calls and
scripts, and databases have controls for data presentation and retention, as well as stored
procedures and other database implementation-specific aspects.
Network devices and Infrastructure
195 | P a g e
Network devices such as routers, switches and firewalls all have specific controls that apply to
segmentation of network traffic, inspection of traffic and encryption of traffic.
For each of these four categories of infrastructure elements, there are significant numbers of
configuration controls that can be applied to implement a specific security or compliance goal. All
organizations will have basic physical security controls around hosts, but financial services
organizations might have many additional layers of network security controls compared to a small
software firm. The software firm, however, might have many more complex code repositories,
databases and application-specific controls for some systems. In the case of virtualization, other
layers of configuration controls are called for, such as locking down virtual machine files and
securing the hypervisor.
The sum of these controls constitutes a security or compliance posture that operates within the
framework of internal policies and external regulations and mandates. While that sounds simple
enough, managing these controls and processes has been difficult for organizations to follow
holistically. For example, they may be managing their virtual hosts, but upgrades to the host
platform may affect the virtual guest systems that run on it, leading to modifications in operating
system parameters. Over time, the virtual hosts slip out of compliance with the CIS Windows 2008
Server benchmark that serves as their corporate configuration standard—most likely without the
organization’s knowledge. Because this standard is what the auditing program has been built on,
such change could lead to a failed audit or compliance violation as well as risky exposure.
Whether in an IT environment that is managed internally, virtually or in the cloud, the primary
culprit behind changes that “get out of hand” is, for most organization, a lack of visibility. This lack of
visibility can be seen in a number of forms, including the following:
Network Visibility
Different subnets are segregated in such a way that certain systems cannot be identified from other
parts of the network, or configurations are only visible to network operations teams.
Application Visibility
Ports and services may be unavailable to certain networks, groups or individuals.
Configuration Visibility
Certain groups and individuals may not have the access rights to determine a system or application’s
configuration options.
Communication Issues
Certain groups may intentionally or accidentally withhold information from other teams, which leads
to a lack of visibility.
196 | P a g e
Without the proper visibility, many teams will not be up-to-date on what systems are deployed,
what state those systems are in, and how these changes and discrepancies may affect other parts of
the organization. This lack of communication presents the window of opportunity attackers look for
to exploit.
Aside from lack of visibility, many organizations have a tendency to leave the definition,
management and governance of configuration management to individual groups or silos within IT.
Rather than defining a central configuration management team that coordinates tools, processes
and policies related to configuration management, many organizations let individual teams of
administrators and engineers choose how and when to update and manage system configuration
details. Organizations need a coordinated configuration management database or a well-maintained
catalog of CIs that all teams refer to for baselines and updates. In most cases, not having such a
resource is attributed to staff members not having enough time or senior management lacking
commitment. Many IT professionals also feel there is not enough operational capacity to implement
and manage a configuration management solution. These silos also lead to gaps in coverage of
critical systems that open the doors to exploitation. There are also challenges with the technical
aspects of configuration management. Tools that can both implement and manage configuration
details for most platforms tend to come in agent-based formats, with some offering non-agentbased assessment mechanisms as well. Most organizations prefer not to install yet another agent on
their systems if possible, due to the perception of reduced performance, more overhead, and
possible compatibility issues with other existing software and operating system components. On the
other hand, the agentless options tend to be implemented as remote scanning tools, which may
have limited ability to implement configuration changes even when run with administrative
credentials. The Department of Homeland Security explains in much more detail the pros and cons
of using agents and agentless assessment in its Continuous Asset Evaluation, Situational Awareness,
and Risk Scoring Reference Architecture Report (CAESARS).
From the security perspective, any of these tools should be highly aware of changes to systems, as
these are almost always the leading indicators of, or precursors to, security issues such as illicit
logins, exploited vulnerabilities and malware installation. Ultimately, however, the only true way to
monitor changes to server systems on a continuous basis, as recommended by the SANS 20 Critical
Security Controls and other best practices, is by installing an agent. Yet, network configuration
management tools lend themselves more readily to remote scanning-based assessments, because
many of those operating platforms do not support agents in the first place. For this reason, it’s highly
likely that a combination of both agented and agentless assessments will be required. In fact, SANS
Critical Control 3 reinforces this point in its current language regarding metrics: “Any of these
changes to a computer system must be detected within 24 hours and notification performed by
alerting or sending e-mail notification to a list of enterprise administrative personnel. Systems must
block installation, prevent execution, or quarantine unauthorized software within one additional
hour, alerting or sending e-mail when this action has occurred. Every 24 hours after that point, the
system must alert or send e-mail about the status of the system until it has been removed from the
network or remediated.
197 | P a g e
While the 24-hour and one-hour timeframes represent the current metric to help organizations
improve their state of security, in the future organizations should strive for even more rapid alerting
and isolation, with notification about unauthorized changes sent within two minutes.”15 Along
those lines is another challenge related to the general timeliness of getting CI information and
assessments. A monthly “megascan” is not only invasive, but it is also not sufficiently timely for
critical CIs. A newly created illegal service or unexpected telnet session might be recorded by log or
SIEM systems, but if not acted upon quickly, it could cause significant damage. Instead, if the
security configuration process is real-time and self-reliant (and sometimes self-correcting), it actively
serves as a last line of defence.
Activity 9
What is meant by Configuration Status Accounting and what is its role in Security Configuration
Management?
198 | P a g e
Activity 9
199 | P a g e
Activity 9
Management Once configurations have been applied, systems have a tendency to “shift and drift”
from their original postures, which can lead to woefully insecure configurations that are susceptible
to attacks. Therefore, ongoing management of the secure configuration tools and CIs is critical.
There are several other aspects to proper management of security configuration:
200 | P a g e
Exceptions
The exception process for secure configuration application needs to be tied closely to change
management. When exceptions are required to existing and planned configuration baselines, there
should be extensive documentation of why the exception is needed, along with an approval
workflow.
Waivers
Waivers should only be issued after the exception process has been successfully followed and
documented. In addition, waivers should be revisited regularly to revisit mitigation options.
Risk Management
Regularly evaluating the risks of your current configuration templates and CIs should be a part of the
secure configuration management lifecycle.
Lifecycle
Developing and applying a configuration to servers, workstations and network devices requires a
cyclical approach that ensures configuration controls are updated, patches are applied and systems
are evaluated regularly.
Secure configuration management may allow security and operations teams to truly measure
configuration baselines and then chart improvements over time, providing a rich source of
meaningful metrics. For example, systems may be 50 percent compliant with a chosen configuration
standard at the time of initial assessment, and remediation changes can modify this posture to 70
percent over a period of time dictated by project, change cycles and assigned priorities.
Given the prevalence of breaches directly related to or involving configuration failures for systems
and network devices, it’s important that organizations get back to basics and look at the
fundamentals of securing systems and network devices. Implementing a secure configuration
management program is essential to properly securing systems and data—and meeting compliance
mandates. Unfortunately, many organizations, especially with the advent of virtualization and
private cloud technology, are unable to keep pace with the growing complexity in their
environments. The situation only gets worse without rigorous configuration audits and controls. A
continuous audit of configuration state and new systems coming online is the best way to manage
and monitor all the different infrastructure components that comprise today’s complex
environments. Whatever management structure is put in place, organizations must consider changes
and updates to their environments. Structured change management processes that do exist must
consider that planned and unplanned changes occur out-of-band. Such changes ultimately lead to
the majority of most security breaches.
201 | P a g e
In out-of-band or unmanaged systems, patches aren’t applied, configurations are modified, and new
virtual systems are brought online without any stewardship from risk managers. Using automation
and policy to continuously monitor for changes and auditing configurations are the key means for
mitigating risk in the first place, according to the SANS 20 controls and other authority documents.
Secure configuration management can also help organizations know when something is occurring on
their networks that shouldn’t be. Ultimately, proper secure configuration management should lead
to continuous overall improvement in risk posture through reduced vulnerability and
misconfiguration metrics and cleaner networked systems.
Validate that the engineered ICT system and application security controls
meet the specified requirements
Develop Technical Configuration Standards and Procedures
Especially in the case of large system rollouts, it is likely that the different teams will roll out the
application and the underlying infrastructure.
You should document how to perform these rollout activities securely, in a set of publications that
outline: 1) technical security standards; and 2) technical configuration procedures.
Technical security standards provide detailed rules that define what should be done at a technology
level to mitigate security risks. The standards are related to network or systems infrastructure, for
example, a router, operating system, network switch, or server. Other technical standards are
related to the business applications being rolled out.
Technical configuration procedures provide step-by-step instructions on how to configure an
operating system or service, or a security software tool, such that it adheres to the rules detailed in
the technical standard. For example, there may be step-by-step configuration instructions on how to
securely configure a Windows NT server, or the newly developed application, to comply with
security standards.
Such publications help ensure that personnel are properly hardening the system by removing known
vulnerabilities such as default passwords or unneeded services.
Test Security
The test phase verifies that all of the security-related components of the system work as advertised,
and meet the expectations of owners and end users. In most cases, the security aspects of testing
are integrated with the regular test plan. The exception is vulnerability testing.
The first two tasks are typical test functions, with a security twist. The third task -- vulnerability
assessment -- is a recently developed test function that is specific to security.
202 | P a g e
Conduct Performance/Load Test With Security Features Turned On
This task involves verifying that the system performs up to specification and meets production load
requirements with the security components and features that are engaged.
This task is often overlooked. Do not make the elementary mistake of forgetting to turn on all of the
security features, discussed above, that apply to your system.
Perform Usability Testing of Applications That Have Security Controls
You should verify that security-related functions are ergonomically sound. If personnel are not
accomplishing their work through the applications, for example, because the applications are overly
time-consuming or difficult to use, you have to take remedial steps like training the employees or
reengineering the system.
Perform Independent Vulnerability Assessment of System (Infrastructure and Applications)
You must verify that the infrastructure and applications cannot be compromised, and that attackers
cannot use the applications to carry out unintended functions. Verification is essential prior to an
application being implemented on your system or shipped to a customer, before a security flaw can
do any damage.
Vulnerability assessment has traditionally examined the infrastructure through such "ethical
hacking" means as penetration testing. Still, you must not neglect assessing applications as well,
especially in an Internet environment, where a skillful cracker can manipulate Web applications into
performing unintended functions that compromise data. Crackers put large amounts of data into
fields intended for only a few bytes. This technique, called a buffer overflow attack, can enable an
attacker to directly control a system, or take control later by providing commands as part of the
input string. One of the methods of accomplishing partial application-level vulnerability testing is to
have the functional testing team add a set of negative test cases. Negative test cases refer to
checking various functions, input fields, etc. for the result of unintended inputs. This is the opposite
of positive test cases where the functional testing team is expecting certain results based on various
application inputs. As outlined above, hackers will often try things that the application would not
expect – e.g., buffer overflow situations.
This verification is best performed by an independent organization. This would be an internal
auditing group not associated with the application development effort, or an outside firm. The
development teams have typically worked too closely with the products to objectively assess their
security vulnerabilities.
Independent, third-party verification can help to protect your organization against the threat of legal
liability in the event of security incidents. Vulnerability assessments indicate, in legal parlance, that
your organization is exhibiting "due care" to protect its own assets and that of clients.
203 | P a g e
The courts recognize that there is no such thing as "perfect security." However, through the doctrine
of due care, they do place the burden of taking prudent measures to protect assets upon the
organization responsible for creating and maintaining the infrastructure and applications.
Re-engineer security controls to mitigate vulnerabilities identified during the
operations phase
Perform Design Review
Design reviews tend to be an iterative process. After conducting a high-level review, you work down
to a detailed design review in order to fashion a final design.
The high-level review should include an examination of requirements and current architectures,
design solutions, a review of vulnerabilities, and an assessment of whether and how vulnerabilities
can be eliminated.
The detailed review should include a formal walkthrough. A key security-related area to check is the
performance requirements and sizing of the system infrastructure (networks, servers, etc.), since
security services will often overload services.
It is important to go through a set of design reviews focused on the security aspects of the system.
Depending on the design area being reviewed, business, application development, and security
personnel should take part in these reviews.
The series of design reviews should include the following:
• Technical review geared to the application level
• Technical review geared to the infrastructure level
• Non-technical review (processes and procedures)
Ensure integration of information security practices throughout the SDLC
process
Educate Development Teams on How to Create a Secure System
The two main aspects of this task are:
• Provide best practices for secure coding.
• Provide practical education on using the various security tools and services.
204 | P a g e
Application teams are, naturally, usually well-schooled in the art of development. However, they
frequently do not understand the security aspects of development. The application teams require
education and training in such matters as secure coding practices. They need to learn how to identify
common vulnerabilities, and how to establish secure development environments. In addition,
developers should be exposed, like the rest of the organization, to the general security principles.
Another aspect of this task relates to training developers in specific security tools and services. In
newer systems, developers make frequent use of external security services by means of application
program interface (API) calls. In the "good old days" of mainframe "legacy system coding", many
security-related functions like authentication and auditing were done within the application. In
modern Web environments, by contrast, many security functions like access control are done via
middleware services. In such settings, the developers can use within the operating environment a
set of third-party tools, such as PKI, or services layered into operating systems, such as logging,
auditing, authentication, etc. to accomplish security functions.
Design End-User Training Awareness Measures
The design of a training and awareness program is vitally important. All the security processes and
hardware in the world will do little good if your personnel does not know how to use them. This is
often missed or overlooked in training manuals and courses. In Web applications, especially with
external users, security training and awareness often must be built into the application, or
incorporated in "getting started" type of user education tools.
Document ICT system or application security controls addressed within the
system
Assess and Document How to Mitigate Key Application and Infrastructure Vulnerabilities
This task is a variation of bug tracking, in which you highlight security-related deficiencies. You have
several options for handling these flaws. You can remove or mitigate them by tuning the design or
reconfiguring the infrastructure. Alternately, if you are unable to eliminate or lessen vulnerabilities,
you can deter them, or at least monitor for their occurrence.
A parking lot owner wishing to reduce car thefts, for example, might deter thieves with extra street
lighting, and monitor suspicious activity with surveillance cameras. In the Internet world, you could
deter intruders by posting warning banners or copyright notices on your Web site. Some
vulnerabilities may prove impossible to fix, and others prohibitively expensive to address. You
definitely want to monitor for such vulnerabilities. You might watch for would-be crackers through,
for example, intrusion detection products that detect tell-tale signs of attacks.
205 | P a g e
Practise secure coding
Secure coding practices must be incorporated into all life cycle stages of an application development
process. The following minimum set of secure coding practices should be implemented when
developing and deploying covered applications:
Formalize and document the software development life cycle (SDLC) processes to
incorporate major component of a development process:
o
o
o
o
o
o
Requirements
Architecture and Design
Implementation
Testing
Deployment
Maintenance
Develop (Build/Configure/Integrate)
The development phase implements the requirements and architecture/design decisions.
Your security goals can be applied during the development phase. With some high-risk systems, a
secure development environment is set up during this phase. This would include the proper policies
and procedures to protect the integrity and confidentiality of the code, the designs, and underlying
development infrastructure from related attacks such as theft or destruction.
The essential part of development is coding, that is, the writing of the actual programming code.
Some companies have coding standards -- specific rules for code structure and appearance.
Standards can prolong the life of the code, and make it easier to maintain. Writing secure code from
the start saves time and money during testing and the remainder of the life cycle.
Many organizations are adopting secure coding standards to ensure that the code is secure. To
achieve this aim, developers should use defensive programming techniques.
Examples of security-related development considerations are:
• Identify, in terms of security, the weaknesses and strengths of the programming language.
• Put system source code and related configuration files in a secure environment, preferably one
isolated from the rest of the network.
• Set up a code/component version control system.
• Develop operational procedures (based on the CONOP). Ensure that network and systems
administrators, partners, customers, and integration firms that deploy the solution or solution
components meet the requirements outlined in the technical standards for the mitigation of
vulnerabilities.
206 | P a g e
Defensive techniques are further detailed in the METASeS publication Building Secure e-Commerce
Applications.
With the implementation of a standard set of secure coding practices, your organization will have a
much easier time understanding the most common risks you deal with and learn the best ways to fix
and prevent similar issues in the future33.
1. Secure by Design
Today’s worst kinds of application vulnerabilities are realized when malicious actors exploit bugs
that allow them to steal, change or delete data. These attacks use vulnerabilities like SQL injection
and cross-site scripting, which, while fairly simple to fix, still somehow manage to run rampant and
wreak havoc in our software.
The solution, which is never easy but will save time and damage later, is to design your applications
with security at top of mind. Making your applications secure by design is the number one practice
on this list because it’s a prerequisite for the security principles to follow.
In Practice:


During the design stage, make sure that security policies are implemented within the
architecture.
Ensure source code analysis is implemented throughout your SDLC, so that vulnerabilities
are detected and can be fixed as soon as they’re written.
2. Threat Modeling
Determining the greatest threats and risks posed by your applications is a fundamental part of
secure code. You most likely won’t be able to fix all issues immediately, all the time, so identifying
your most valuable assets and the most severe vulnerabilities will tell you what needs to get fixed
and how quickly.
In Practice:


Perform source code analysis both on applications in their design stage as well as legacy
applications or software with legacy code to find all vulnerabilities, before analyzing their
risk level.
Use a threat modeling tool to automate the process of evaluating and analyzing risk, saving
time for the remediation work.
33
Source: Checkmarx, as at https://www.checkmarx.com/2015/07/01/9-secure-coding-practices-you-cantignore/, as on 10th May, 2017.
207 | P a g e
3. Keep Security Simple
Complexity makes security easy to ignore and fail. If there are too many separate tools and
processes included in properly securing a function, they won’t all be followed. Making the process as
simple as possible for all involved will go far in getting the organization as a whole to adopt these
principles.
In Practice:




Reuse components that you know to be trusted.
Avoid complex architecture and coding with double negatives (more at OWASP).
Centralize your approaches by making the fundamentals part of your design.
Integrate your security tools within the developers already-familiar environments, including
their IDE, build management, source repository, bug tracking system, etc.
4. Defense in Depth
At the same time that we’re making security as simple as possible, we need to practice ‘defense in
depth.’ It’s a balance that needs to be weighed by the various risks posed. The principle of defense in
depth is all about layering our defense tools in order to minimize the number of holes in our
application that would allow different attacks to take place.
The idea behind defense in depth, of course, is that if one security layer fails, the next will be there
to catch whatever attacks fall through the cracks of the first layer. How many layers and which tools
are required are different for each organization.
In Practice:



Find the best mix of SAST, DAST, Pen-testing, RASP and IAST for your organization, and make
sure they’re baked directly into the SDLC.
Ensure that your applications Administrative Interface does not allow unauthorized access
by non-admins.
Use secure development techniques within secure runtime environments.
5. Least Privilege
Access within applications needs to be carefully designed so that each account has the appropriate –
in this case, the least – amount of privilege necessary for their needs or responsibilities.
Consider any applications that offer first-time users default passwords for the initial login session. To
make it harder for malicious actors to get their hands on them, make sure each default password is
different, complex, and only usable for a limited time.
In Practice:

Create a data classification system to help easily designates appropriate, role-based
privileges for all data.
208 | P a g e

Perform access control validations to ensure users are authorized to perform any given task,
as well as terminating sessions that don’t pass an authorization check.

Centralize the above routines so that any errors or vulnerabilities will be fixed throughout
the application.
6. Positive Security
Define what is allowed and reject everything else. This model, also called whitelisting, is the only
true method of preventing unwanted attacks that weren’t thought of during development. New
malware pops up on a regular basis, so it’s already impossible to keep your applications up to date in
that sense. With application whitelisting, the attack surface is limited only to the number of risks it
has accepted through the earlier discussed practice of threat modeling.
In Practice:


Never trust user input (a common theme in these practices and one not to be ignored)!
To keep in line with the earlier practice of keeping security simple, be sure to use a
whitelisting solution that will be easy for admins.
7. Fail Securely
Bruce Schneier wrote it perfectly: “ When an ATM fails, it shuts down; it doesn’t spew money out its
slot.”
Realize that failure is unavoidable and your applications will fail – make sure you (and they) are
prepared. Instead, we need to ensure our software is prepared to fail without offering up sensitive
data in the process.
In Practice:



Ensuring that least privilege is followed will help you in failing securely by denying
unauthenticated access.
If there is an error processing the login information, make sure your application doesn’t
disclose any more information than a generic error
Always log the failure for further analysis later on to understand the error strategy and see
what improvements can be made.
8. Avoid Security by Obscurity
Security by Obscurity does NOT work. We’ve seen it fail time and time again, yet some organizations
still don’t seem to get it. For example, while demanding your users and employees use strong
passwords offers one layer of security by obscurity, you can’t just rely on that. You still need to
sanitize inputs, secure your database, and log inconsistencies for later analysis.
209 | P a g e
Perhaps one of the best ways to avoid security by obscurity is to assume your source code has
already been taken. That would be a worst-case scenario, but we can’t keep holding our fingers
crossed hoping a vulnerability won’t be discovered before you can fix it.
In Practice:


Assume your source code has been compromised and always ensure proper security testing.
Threat modeling and defense in depth are two principles that will help in knowing where
you’re most vulnerable so you can decide how to move forward.
9 .Complete Remediation
Last, yet certainly not least, is the principle of fully understanding and remediating risky
vulnerabilities. Only through proper testing and training can an organization truly cut down on their
security risks by learning from past mistakes and planning for the future. Completely remediating
those vulnerabilities that hold your code back is the only way you can truly move forward in your
security program.
This is where source code analysis works especially well, both in regards to testing for security issues
and tracking the issue fixes. As the OWASP Testing Guide – a highly valuable resource for all
application stakeholders – states:
Source code analysis and unit tests can validate that the code change mitigates the vulnerability
exposed by the previously identified coding defect.
The results of automated secure code analysis can also be used as automatic check-in gates for
version control, for example software artifacts cannot be checked into the build with high or
medium severity coding issues.
In Practice:

Using a visualized graph such as the one CxSAST offers adds value by saving time and later
issues by providing an in-depth analysis of the issues found in your code – and the best
locations to fix them for maximum remediation in minimal effort and tampering.
Activity 10
Who are the primary users of documentation throughout the SDLC?
210 | P a g e
Activity 10
211 | P a g e
Activity 10
212 | P a g e
Activity 10
Review new and existing risk management technologies to achieve an
optimal enterprise risk posture
Operations/Maintenance
After the system is deployed, you continue to operate and maintain it. From a security perspective,
operations and maintenance may include:
• Test and migrate to new software versions. Especially important because vulnerability conditions
change over time. Patches and service packs will address known vulnerabilities.
• Conduct periodic risk review and consult with the business/application owner to assess whether
risks have changed. Make appropriate upgrades or downgrades.
• Continue to provide as well as strengthen the security awareness program, reminding end users of
the things they need to do to maintain security. This is important because new users are added and
new vulnerabilities arise continually, and existing users tend to let down their guard .
• Conduct periodic vulnerability assessments. Be aware that hackers are discovering new
vulnerabilities and devising new threats all the time. It is critical to catch vulnerabilities in a new
release before the application is made public. You should perform quarterly to yearly vulnerability
assessments, based on the risk profile of applications. It is particularly important to perform
vulnerability assessments with new releases of the system, as this is often when new vulnerabilities
arise.
• Perform auditing, logging, monitoring, archiving. This should include periodic audits of processes
and procedures, as well as ongoing review of logs, especially when monitoring for known
weaknesses.
Risk management is an ongoing, never ending process. Within this process implemented security
measures are regularly monitored and reviewed to ensure that they work as planned and that
changes in the environment rendered them ineffective. Business requirements, vulnerabilities and
threats can change over the time.
213 | P a g e
Regular audits should be scheduled and should be conducted by an independent party, i.e.
somebody not under the control of whom is responsible for the implementations or daily
management of ISMS.
Review new and existing ICT security technologies to support secure
engineering across the SDLC phases
Design a Security Test Plan
You should perform a basic check of the components of the system test plan. Security needs to be
wrapped into the overall test plan. It should be communicated to the integration and deployment
teams.
In addition to traditional systems testing, you want to focus on certain specific areas. These include:
• Usability/Ergonomics Testing – Checks that security features function, and are reasonably well
understood and easy to use. If the security features do not have these characteristics, they will be
ignored or will cause problems. Usability/ergonomics is typically applied to applications themselves,
but can be applied to security-related matters as well.
• Performance Testing – Checks that the system efficiency performs as required. This is traditionally
done as part of the regular SDLC. However, as mentioned above, testing after turning on the
security-related features -- authentication, encryption, etc. -- is important in determining if system
performance is adequate. The impact of security features on performance is often not noticed until
after the system is put into production.
• Vulnerability Testing – Also known as penetration testing or "ethical hacking", attempts to uncover
critical vulnerabilities so that they can be fixed before production. Because vulnerability testing is
not part of the traditional SDLC, it is often overlooked.
Security controls should be validated. Technical controls are possible complex systems that are to
tested and verified. The hardest part to validate is people knowledge of procedural controls and the
effectiveness of the real application in daily business of the security procedures.
Vulnerability assessment, both internal and external, and Penetration test are instruments for
verifying the status of security controls.
Information technology security audit is an organizational and procedural control with the aim of
evaluating security. The IT systems of most organization are evolving quite rapidly. Risk management
should cope with these changes through change authorization after risk re-evaluation of the affected
systems and processes and periodically review the risks and mitigation actions.
214 | P a g e
Monitoring system events according to a security monitoring strategy, an incident response plan and
security validation and metrics are fundamental activities to assure that an optimal level of security
is obtained. It is important to monitor the new vulnerabilities, apply procedural and technical
security controls like regularly updating software, and evaluate other kinds of controls to deal with
zero-day attacks.
The attitude of involved people to benchmark against best practice and follow the seminars of
professional associations in the sector are factors to assure the state of art of an organization IT risk
management practice.
Continually assess effectiveness of the information system controls based on
risk management practices and procedures
Perform Ongoing Vulnerability Monitoring
Crackers continually develop new tools and techniques for exploiting vulnerabilities. You need a
process for the continual monitoring of new vulnerabilities. A number of organizations, such as
Bugtraq, CERT, and METASeS – through its Web Alert service – provide a service that keeps you
informed of the latest security vulnerabilities.
Because you will not be able to eliminate all vulnerabilities, you will want to regularly monitor holes
in your defences. This is typically done through an Intrusion Detection System (IDS). (METASeS
conducts "ethical hacking" of clients through an IDS to probe for vulnerabilities.) Because it is
impossible to close every hole, a key ability is to react swiftly and effectively in the event of a
security incident.
For example, a Denial of Service (DoS) attack is nearly impossible to prevent. However, you can
monitor for DoS attacks, engineer system redundancies and failovers to mitigate the negative impact
of a DoS, and have a plan of action ready in case one occurs.
NOTE: Later versions of this report will discuss packaged applications, including those provided by
application service providers, and those purchased commercially off-the-shelf (COTS), for example,
SAP and PeopleSoft.
Improving information management practices is a key focus for many organisations, across both the
public and private sectors34.
This is being driven by a range of factors, including a need to improve the efficiency of business
processes, the demands of compliance regulations and the desire to deliver new services.
34
Source: Step Two, as at http://www.steptwo.com.au/papers/kmc_effectiveim/, as on 10th May, 2017.
215 | P a g e
In many cases, ‘information management’ has meant deploying new technology solutions, such as
content or document management systems, data warehousing or portal applications.
These projects have a poor track record of success, and most organisations are still struggling to
deliver an integrated information management environment.
Effective information management is not easy. There are many systems to integrate, a huge range of
business needs to meet, and complex organisational (and cultural) issues to address.
This article draws together a number of ‘critical success factors’ for information management
projects. These do not provide an exhaustive list, but do offer a series of principles that can be used
to guide the planning and implementation of information management activities.
From the outset, it must be emphasised that this is not an article about technology. Rather, it is
about the organisational, cultural and strategic factors that must be considered to improve the
management of information within organisations.
Exploring information management
‘Information management’ is an umbrella term that encompasses all the systems and processes
within an organisation for the creation and use of corporate information.
In terms of technology, information management encompasses systems such as:









web content management (CM)
document management (DM)
records management (RM)
digital asset management (DAM)
learning management systems (LM)
learning content management systems (LCM)
collaboration
enterprise search
and many more…
Information management is, however, much more than just technology. Equally importantly, it is
about the business processes and practices that underpin the creation and use of information.
It is also about the information itself, including the structure of information (‘information
architecture’), metadata, content quality, and more.
Information management therefore encompasses:




people
process
technology
content
216 | P a g e
Each of these must be addressed if information management projects are to succeed.
Information management challenges
Organisations are confronted with many information management problems and issues. In many
ways, the growth of electronic information (rather than paper) has only worsened these issues over
the last decade or two.
Common information management problems include:














Large number of disparate information management systems.
Little integration or coordination between information systems.
Range of legacy systems requiring upgrading or replacement.
Direct competition between information management systems.
No clear strategic direction for the overall technology environment.
Limited and patchy adoption of existing information systems by staff.
Poor quality of information, including lack of consistency, duplication, and out-of-date
information.
Little recognition and support of information management by senior management.
Limited resources for deploying, managing or improving information systems.
Lack of enterprise-wide definitions for information types and values (no corporate-wide
taxonomy).
Large number of diverse business needs and issues to be addressed.
Lack of clarity around broader organisational strategies and directions.
Difficulties in changing working practices and processes of staff.
Internal politics impacting on the ability to coordinate activities enterprise-wide.
While this can be an overwhelming list, there are practical ways of delivering solutions that work
within these limitations and issues.
Ten principles
This article introduces ten key principles to ensure that information management activities are
effective and successful:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
recognise (and manage) complexity
focus on adoption
deliver tangible & visible benefits
prioritise according to business needs
take a journey of a thousand steps
provide strong leadership
mitigate risks
communicate extensively
aim to deliver a seamless user experience
choose the first project very carefully
Each of these is discussed in the sections below.
217 | P a g e
Future articles will explore additional principles and guidelines, as well as providing a concrete
approach to developing an overarching information management strategy.
Principle 1: recognise (and manage) complexity
Organisations are very complex environments in which to deliver concrete solutions. As outlined
above, there are many challenges that need to be overcome when planning and implementing
information management projects.
When confronted with this complexity, project teams often fall back upon approaches such as:






Focusing on deploying just one technology in isolation.
Purchasing a very large suite of applications from a single vendor, in the hope that this can
be used to solve all information management problems at once.
Rolling out rigid, standardised solutions across a whole organisation, even though individual
business areas may have different needs.
Forcing the use of a single technology system in all cases, regardless of whether it is an
appropriate solution.
Purchasing a product ‘for life’, even though business requirements will change over time.
Fully centralising information management activities, to ensure that every activity is tightly
controlled.
All of these approaches will fail, as they are attempting to convert a complex set of needs and
problems into simple (even simplistic) solutions. The hope is that the complexity can be limited or
avoided when planning and deploying solutions.
In practice, however, there is no way of avoiding the inherent complexities within organisations.
New approaches to information management must therefore be found that recognise (and manage)
this complexity.
Organisations must stop looking for simple approaches, and must stop believing vendors when they
offer ‘silver bullet’ technology solutions.
Instead, successful information management is underpinned by strong leadership that defines a
clear direction (principle 6). Many small activities should then be planned to address in parallel the
many needs and issues (principle 5).
Risks must then be identified and mitigated throughout the project (principle 7), to ensure that
organisational complexities do not prevent the delivery of effective solutions.
Principle 2: focus on adoption
Information management systems are only successful if they are actually used by staff, and it is not
sufficient to simply focus on installing the software centrally.
218 | P a g e
In practice, most information management systems need the active participation of staff throughout
the organisation.
For example:




Staff must save all key files into the document/records management system.
Decentralised authors must use the content management system to regularly update the
intranet.
Lecturers must use the learning content management system to deliver e-learning packages
to their students.
Front-line staff must capture call details in the customer relationship management system.
In all these cases, the challenge is to gain sufficient adoption to ensure that required information is
captured in the system. Without a critical mass of usage, corporate repositories will not contain
enough information to be useful.
This presents a considerable change management challenge for information management projects.
In practice, it means that projects must be carefully designed from the outset to ensure that
sufficient adoption is gained.
This may include:





Identifying the ‘what’s in it for me’ factors for end users of the system.
Communicating clearly to all staff the purpose and benefits of the project.
Carefully targeting initial projects to build momentum for the project (see principle 10).
Conducting extensive change management and cultural change activities throughout the
project.
Ensuring that the systems that are deployed are useful and usable for staff.
These are just a few of the possible approaches, and they demonstrate the wide implications of
needing to gain adoption by staff.
Principle 3: deliver tangible & visible benefits
It is not enough to simply improve the management of information ‘behind the scenes’. While this
will deliver real benefits, it will not drive the required cultural changes, or assist with gaining
adoption by staff (principle 2).
In many cases, information management projects initially focus on improving the productivity of
publishers or information managers.
While these are valuable projects, they are invisible to the rest of the organisation. When
challenged, it can be hard to demonstrate the return on investment of these projects, and they do
little to assist project teams to gain further funding.
Instead, information management projects must always be designed so that they deliver tangible
and visible benefits.
219 | P a g e
Delivering tangible benefits involves identifying concrete business needs that must be met (principle
4). This allows meaningful measurement of the impact of the projects on the operation of the
organisation.
The projects should also target issues or needs that are very visible within the organisation. When
solutions are delivered, the improvement should be obvious, and widely promoted throughout the
organisation.
For example, improving the information available to call centre staff can have a very visible and
tangible impact on customer service.
In contrast, creating a standard taxonomy for classifying information across systems is hard to
quantify and rarely visible to general staff.
This is not to say that ‘behind the scenes’ improvements are not required, but rather that they
should always be partnered with changes that deliver more visible benefits.
This also has a major impact on the choice of the initial activities conducted (principle 10).
Principle 4: prioritise according to business needs
It can be difficult to know where to start when planning information management projects.
While some organisations attempt to prioritise projects according to the ‘simplicity’ of the
technology to be deployed, this is not a meaningful approach. In particular, this often doesn’t deliver
short-term benefits that are tangible and visible (principle 3).
Instead of this technology-driven approach, the planning process should be turned around entirely,
to drive projects based on their ability to address business needs.
In this way, information management projects are targeted at the most urgent business needs or
issues. These in turn are derived from the overall business strategy and direction for the organisation
as a whole.
For example, the rate of errors in home loan applications might be identified as a strategic issue for
the organisation. A new system might therefore be put in place (along with other activities) to better
manage the information that supports the processing of these applications.
Alternatively, a new call centre might be in the process of being planned. Information management
activities can be put in place to support the establishment of the new call centre, and the training of
new staff.
Principle 5: take a journey of a thousand steps
There is no single application or project that will address and resolve all the information
management problems of an organisation.
220 | P a g e
Where organisations look for such solutions, large and costly strategic plans are developed.
Assuming the results of this strategic planning are actually delivered (which they often aren’t), they
usually describe a long-term vision but give few clear directions for immediate actions.
In practice, anyone looking to design the complete information management solution will be trapped
by ‘analysis paralysis’: the inability to escape the planning process.
Organisations are simply too complex to consider all the factors when developing strategies or
planning activities.
The answer is to let go of the desire for a perfectly planned approach. Instead, project teams should
take a ‘journey of a thousand steps’.
This approach recognises that there are hundreds (or thousands) of often small changes that are
needed to improve the information management practices across an organisation. These changes
will often be implemented in parallel.
While some of these changes are organisation-wide, most are actually implemented at business unit
(or even team) level. When added up over time, these numerous small changes have a major impact
on the organisation.
This is a very different approach to that typically taken in organisations, and it replaces a single large
(centralised) project with many individual initiatives conducted by multiple teams.
While this can be challenging to coordinate and manage, this ‘thousand steps’ approach recognises
the inherent complexity of organisations (principle 1) and is a very effective way of mitigating risks
(principle 7).
It also ensures that ‘quick wins’ can be delivered early on (principle 3), and allows solutions to be
targeted to individual business needs (principle 4).
Principle 6: provide strong leadership
Successful information management is about organisational and cultural change, and this can only
be achieved through strong leadership.
The starting point is to create a clear vision of the desired outcomes of the information management
strategy. This will describe how the organisation will operate, more than just describing how the
information systems themselves will work.
Effort must then be put into generating a sufficient sense of urgency to drive the deployment and
adoption of new systems and processes.
Stakeholders must also be engaged and involved in the project, to ensure that there is support at all
levels in the organisation.
221 | P a g e
This focus on leadership then underpins a range of communications activities (principle 8) that
ensure that the organisation has a clear understanding of the projects and the benefits they will
deliver.
When projects are solely driven by the acquisition and deployment of new technology solutions, this
leadership is often lacking. Without the engagement and support of key stakeholder outside the IT
area, these projects often have little impact.
Principle 7: mitigate risks
Due to the inherent complexity of the environment within organisations (principle 1), there are
many risks in implementing information management solutions. These risks include:





selecting an inappropriate technology solution
time and budget overruns
changing business requirements
technical issues, particularly relating to integrating systems
failure to gain adoption by staff
At the outset of planning an information management strategy, the risks should be clearly identified.
An approach must then be identified for each risk, either avoiding or mitigating the risk.
Risk management approaches should then be used to plan all aspects of the project, including the
activities conducted and the budget spent.
For example, a simple but effective way of mitigating risks is to spend less money. This might involve
conducting pilot projects to identifying issues and potential solutions, rather than starting with
enterprise-wide deployments.
Principle 8: communicate extensively
Extensive communication from the project team (and project sponsors) is critical for a successful
information management initiative.
This communication ensures that staff have a clear understanding of the project, and the benefits it
will deliver. This is a pre-requisite for achieving the required level of adoption.
With many projects happening simultaneously (principle 5), coordination becomes paramount. All
project teams should devote time to work closely with each other, to ensure that activities and
outcomes are aligned.
In a complex environment, it is not possible to enforce a strict command-and-control approach to
management (principle 1).
222 | P a g e
Instead, a clear end point (‘vision’) must be created for the information management project, and
communicated widely. This allows each project team to align themselves to the eventual goal, and
to make informed decisions about the best approaches.
For all these reasons, the first step in an information management project should be to develop a
clear communications ‘message’. This should then be supported by a communications plan that
describes target audiences, and methods of communication.
Project teams should also consider establishing a ‘project site’ on the intranet as the outset, to
provide a location for planning documents, news releases, and other updates.
Principle 9: aim to deliver a seamless user experience
Users don’t understand systems. When presented with six different information systems, each
containing one-sixth of what they want, they generally rely on a piece of paper instead (or ask the
person next to them).
Educating staff in the purpose and use of a disparate set of information systems is difficult, and
generally fruitless. The underlying goal should therefore be to deliver a seamless user experience,
one that hides the systems that the information is coming from.
This is not to say that there should be one enterprise-wide system that contains all information.
There will always be a need to have multiple information systems, but the information contained
within them should be presented in a human-friendly way.
In practice, this means:



Delivering a single intranet (or equivalent) that gives access to all information and tools.
Ensuring a consistent look-and-feel across all applications, including standard navigation and
page layouts.
Providing ‘single sign-on’ to all applications.
Ultimately, it also means breaking down the distinctions between applications, and delivering tools
and information along task and subject lines.
For example, many organisations store HR procedures on the intranet, but require staff to log a
separate ‘HR self-service’ application that provides a completely different menu structure and
appearance.
Improving on this, leave details should be located alongside the leave form itself. In this model, the
HR application becomes a background system, invisible to the user.
Care should also be taken, however, when looking to a silver-bullet solution for providing a seamless
user experience. Despite the promises, portal applications do not automatically deliver this.
223 | P a g e
Instead, a better approach may be to leverage the inherent benefits of the web platform. As long as
the applications all look the same, the user will be unaware that they are accessing multiple systems
and servers behind the scenes.
Of course, achieving a truly seamless user experience is not a short-term goal. Plan to incrementally
move towards this goal, delivering one improvement at a time.
Principle 10: choose the first project very carefully
The choice of the first project conducted as part of a broader information management strategy is
critical. This project must be selected carefully, to ensure that it:







demonstrates the value of the information management strategy
builds momentum for future activities
generates interest and enthusiasm from both end-users and stakeholders
delivers tangible and visible benefits (principle 3)
addresses an important or urgent business need (principle 4)
can be clearly communicated to staff and stakeholders (principle 8)
assists the project team in gaining further resources and support
Actions speak louder than words. The first project is the single best (and perhaps only) opportunity
to set the organisation on the right path towards better information management practices and
technologies.
The first project must therefore be chosen according to its ability to act as a ‘catalyst’ for further
organisational and cultural changes.
In practice, this often involves starting with one problem or one area of the business that the
organisation as a whole would be interested in, and cares about.
For example, starting by restructuring the corporate policies and procedures will generate little
interest or enthusiasm. In contrast, delivering a system that greatly assists salespeople in the field
would be something that could be widely promoted throughout the organisation.
Implementing information technology solutions in a complex and ever-changing organisational
environment is never easy.
The challenges inherent in information management projects mean that new approaches need to be
taken, if they are to succeed.
This article has outlined ten key principles of effective information management. These focus on the
organisational and cultural changes required to drive forward improvements.
The also outline a pragmatic, step-by-step approach to implementing solutions that starts with
addressing key needs and building support for further initiatives. A focus on adoption then ensures
that staff actually use the solutions that are deployed.
224 | P a g e
Of course, much more can be written on how to tackle information management projects. Future
articles will further explore this topic, providing additional guidance and outlining concrete
approaches that can be taken.
Assess and evaluate system compliance with corporate policies and
architectures
Integrating risk management into system development life cycle35
Effective risk management must be totally integrated into the SDLC. An IT system’s SDLC has five
phases: initiation, development or acquisition, implementation, operation or maintenance, and
disposal. The risk management methodology is the same regardless of the SDLC phase for which the
assessment is being conducted. Risk management is an iterative process that can be performed
during each major phase of the SDLC.
Table 2-1 Integration of Risk Management into the SDLC[8]
SDLC Phases
Phase Characteristics
Support from Risk Management
Activities
Phase 1: Initiation The need for an IT system is
Identified risks are used to support the
expressed and the purpose and
development of the system
scope of the IT system is
requirements, including security
documented
requirements, and a security concept of
operations (strategy)
Phase 2:
The IT system is designed,
The risks identified during this phase can
Development or
purchased, programmed,
be used to support the security analyses
Acquisition
developed, or otherwise
of the IT system that may lead to
constructed
architecture and design tradeoffs during
system development
Phase 3:
The system security features
The risk management process supports
Implementation
should be configured, enabled,
the assessment of the system
tested, and verified
implementation against its requirements
and within its modeled operational
environment. Decisions regarding risks
identified must be made prior to system
operation
Phase 4:
The system performs its
Risk management activities are
Operation or
functions. Typically the system is performed for periodic system
Maintenance
being modified on an ongoing
reauthorization (or reaccreditation) or
basis through the addition of
whenever major changes are made to an
hardware and software and by
IT system in its operational, production
35
Source: Revolvy, as at
https://www.revolvy.com/main/index.php?s=IT%20risk%20management&item_type=topic&sr=50, as on 10th
May, 2017.
225 | P a g e
Phase 5: Disposal
changes to organizational
processes, policies, and
procedures
This phase may involve the
disposition of information,
hardware, and software.
Activities may include moving,
archiving, discarding, or
destroying information and
sanitizing the hardware and
software
environment (e.g., new system
interfaces)
Risk management activities are
performed for system components that
will be disposed of or replaced to ensure
that the hardware and software are
properly disposed of, that residual data is
appropriately handled, and that system
migration is conducted in a secure and
systematic manner
NIST SP 800-64 is devoted to this topic.
Early integration of security in the SDLC enables agencies to maximize return on investment in their
security programs, through:




Early identification and mitigation of security vulnerabilities and misconfigurations, resulting
in lower cost of security control implementation and vulnerability mitigation;
Awareness of potential engineering challenges caused by mandatory security controls;
Identification of shared security services and reuse of security strategies and tools to reduce
development cost and schedule while improving security posture through proven methods
and techniques; and
Facilitation of informed executive decision making through comprehensive risk management
in a timely manner.
This guide[22] focuses on the information security components of the SDLC. First, descriptions of the
key security roles and responsibilities that are needed in most information system developments are
provided. Second, sufficient information about the SDLC is provided to allow a person who is
unfamiliar with the SDLC process to understand the relationship between information security and
the SDLC. The document integrates the security steps into the linear, sequential (a.k.a. waterfall)
SDLC. The five-step SDLC cited in the document is an example of one method of development and is
not intended to mandate this methodology. Lastly, SP 800-64 provides insight into IT projects and
initiatives that are not as clearly defined as SDLC-based developments, such as service-oriented
architectures, cross-organization projects, and IT facility developments.
Security can be incorporated into information systems acquisition, development and maintenance
by implementing effective security practices in the following areas.[23]






Security requirements for information systems
Correct processing in applications
Cryptographic controls
Security of system files
Security in development and support processes
Technical vulnerability management
226 | P a g e
Information systems security begins with incorporating security into the requirements process for
any new application or system enhancement. Security should be designed into the system from the
beginning. Security requirements are presented to the vendor during the requirements phase of a
product purchase. Formal testing should be done to determine whether the product meets the
required security specifications prior to purchasing the product.
Correct processing in applications is essential in order to prevent errors and to mitigate loss,
unauthorized modification or misuse of information. Effective coding techniques include validating
input and output data, protecting message integrity using encryption, checking for processing errors,
and creating activity logs.
Applied properly, cryptographic controls provide effective mechanisms for protecting the
confidentiality, authenticity and integrity of information. An institution should develop policies on
the use of encryption, including proper key management. Disk Encryption is one way to protect data
at rest. Data in transit can be protected from alteration and unauthorized viewing using SSL
certificates issued through a Certificate Authority that has implemented a Public Key Infrastructure.
System files used by applications must be protected in order to ensure the integrity and stability of
the application. Using source code repositories with version control, extensive testing, production
back-off plans, and appropriate access to program code are some effective measures that can be
used to protect an application's files.
Security in development and support processes is an essential part of a comprehensive quality
assurance and production control process, and would usually involve training and continuous
oversight by the most experienced staff.
Applications need to be monitored and patched for technical vulnerabilities. Procedures for applying
patches should include evaluating the patches to determine their appropriateness, and whether or
not they can be successfully removed in case of a negative impact.
Problem/Modification Identification Phase
In this phase, software changes are identified, categorized, and assigned an initial priority ranking.
Each software change request is evaluated to determine its classification and handling priority. The
classification types of maintenance are:

Corrective – Change to the software after delivery to correct defects. The changes may
be reported by the "Hot Lines" from the user community.

Adaptive – Change to the software after delivery to keep it functioning properly in a
changing environment. These changes may be initiated and tracked via the Data
Processing Service Request (DPSR) system.

Emergency – Unscheduled corrective maintenance required to keep a system operational.

Scheduled – Change to the software after delivery on a routine basis to improve
performance or maintainability. The changes may be initiated by the users and tracked
by the DPSR system.
227 | P a g e

Perfective – Change to the software after delivery to improve performance or
maintainability. The changes may be initiated by the user and tracked by the DPSR system.
Any number of factors can drive the need for software modifications, including:

Report of system malfunction

Mandatory changes required by new or changed federal or state law

New requirements to support business needs

Minor enhancement or redesign to improve functionality or replace an obsolete system
component

Operational system upgrades and new versions of resident software.
These factors must be considered when assigning a priority to the modification request.
Input to the Problem/Modification Identification Phase of software maintenance is one or more
Modification Requests.
Process
If a modification to the software is required, activities to occur within the maintenance process
include:

Assign an identification number

Categorize the type of maintenance

Analyze the modification to determine whether to accept, reject or further evaluate

Prioritize the modification according to:

Emergency (follow emergency change procedure and integrate into the next schedule
release or block of modifications)

Mandatory (e.g., legal, safety, payroll)

Required (has associated benefits; e.g., productivity gains, new business drivers)

Nice to have (lower priority)
Assess system maturation and readiness for promotion to the production
stage
System Efficiency and Effectiveness
The performance of the system can be measured by two factors, viz., the efficiency and the
effectiveness. The efficiency indicates the manner in which the inputs are used by the system. Being
efficient means the system uses inputs in a `right' way. If the input-output ratio is adverse, we say
that the system is inefficient though it produces the desired output.
228 | P a g e
The effectiveness is the measure for deciding whether the system provides the desired output or
not. Being effective means producing the right output in terms of quantity and quality. When the
system is ineffective, the system is out of control and it needs a major correction.
A system has to be effective and efficient for the highest utility to the user of the system. Broadly
speaking, the effectiveness is a measure of the goodness of the output, while the efficiency is a
measure of the productivity, i.e., the measure of the output against the input.
After the project sponsor or user representative has formally accepted the product, the transition to
operational status begins. The procedures identified in the Transition Plan are used to implement the
transition process. Stress tests, or other operational tests, may be necessary to confirm a sound
installation. The product may require checking to determine tolerances to adverse conditions, failure
modes, recovery methods, and specification margins. Training and certification activities are
completed, as needed. Any support to be provided by contracted services is checked to ensure the
support starts on time.
The project team usually provides operational and technical support during the transition. Project
team members who have a comprehensive understanding of the product need to be identified as
potential support personnel. These individuals may be helpful in providing assistance in the areas of
software installation and maintenance, test, and documentation of changes. Technical support may
involve the analysis of problems in software components and operational procedures, the analysis of
potential enhancements, and vendor supplied upgrades to software components.
Transition to full operational status is an event-oriented process not completed until all transition
activities have been successfully performed. Support provided by project team personnel is typically
withdrawn in a gradual sequence. This aids in the smooth operation of the product and supports user
confidence in the product. A formal transfer of all responsibility to the maintenance staff is planned
at the conclusion of the transition process.
Access to all Project Folder materials, operating documents, identification of any planned
enhancements, and other pertinent records are turned over to the maintenance staff. The software
access rules must be modified to provide access to the maintenance staff and to remove access from
the project team and other temporary users. Programs, files, and other support software must be in
the production library and deleted from the test library, where appropriate.
For major systems involving multiple organizations or interfaces with other systems, a formal
announcement of the transition to production is recommended. The announcement must be
distributed to all affected groups, along with names, telephone numbers, and e-mail addresses of the
maintenance staff.
Maintain Data / Software Administration
Data / Software Administration is needed to ensure the input data and output data and data bases
are correct and continually checked for accuracy and completeness. This includes ensuring that any
regularly scheduled jobs are submitted and completed correctly. Software and data bases are to be
maintained at (or near) the current maintenance level. Data / Software Administration tasks and
activities include:
229 | P a g e

Performing a periodic Verification / Validation of data, correct data related problems;

Performing production control and quality control functions (Job submission, checking
and corrections);

Interfacing with other functional areas for day-to-day checking / corrections;

Installing, configuring, upgrading and maintaining data base(s). This includes updating
processes, data flows, and objects (usually shown in diagrams);

Developing and performing data / data base backup and recovery routines for data
integrity and recoverability. Ensure documented properly in the BOM

Developing and maintaining a performance plan for online process and data bases

Performing configuration/design audits to ensure software, system, parameter
configuration are correct
Acceptance tests are conducted on a fully integrated system by the project sponsor, the user of the
modification package, or a third party designated by the project sponsor. An acceptance test is
conducted on the modified system, with software configuration management.
Inputs
Input for the Acceptance Phase of software maintenance includes:

Test Readiness Review report

Fully integrated system

User Acceptance Test Plan

Acceptance test cases

Acceptance test procedures
Process
The steps forming the process for acceptance testing are:

Perform acceptance tests at the functional level

Perform interoperability testing (to validate any input and output interfaces)

Perform regression testing

Conduct a Functional Configuration Audit (FCA)
The purpose of a FCA is to verify all specified requirements have been met. The audit compares the
system’s software elements with the requirements documented in the Requirements Definition
Document (RDD), to ensure the modifications address all, and only, those requirements. The results
of the FCA must be documented, identifying all discrepancies found, and the plans for the resolution.
Control
Control of acceptance tests includes:
230 | P a g e

Results for the Functional Configuration Audit are reported to ensure all approved
functionality is present in the system

Confirmation is obtained from the change authority indicating the change has been
successfully completed

The new system baseline is established

The acceptance test documentation is placed under software configuration management
control
Outputs
The outputs of the Acceptance Phase include:

New system baseline

Functional Configuration Audit Report

Acceptance Test Report

Updated Project Plan

Updated modification request log
Collect lessons learned from integration of information security into the SDLC
and use to identify improvement actions
These items represent several operational practices that fall outside the boundaries of the leading
secure SDLC frameworks and models such as Microsoft SDL, BSIMM and OpenSAMM. We discovered
that in each of these areas, organizations were making key implementation-level choices that
significantly affected how well their secure SDLC program was being executed36.
Secure SDLC Lesson 1: Application Catalog
Building an application catalog is a critical step towards maintaining governance over a secure SDLC
program. The primary purposes of the catalog are to provide teams information on which
technologies are in place in the enterprise (Java, .Net, third-party libraries, platforms) and criteria for
identifying which applications are mission critical and/or high risk.
Plan
36
Source: Optiv, as at https://www.optiv.com/blog/secure-sdlc-lessons-learned-1-application-catalog, as on
10th May, 2017.
231 | P a g e
It goes without saying that you can’t truly protect what you don’t know you have. Unsurprisingly, the
first step of building the catalog is application discovery. Automated tools are typically used in
conjunction with questionnaires, surveys and interviews to collect the base data.
Inevitably, the question, “What constitutes an application?” will be raised. Very simply, an
application is a set of instructions that requires a running computer process to execute. Common
application types include “thick” or compiled programs that run on client and server tiers, web
applications, mobile applications, RESTful web services and the like. Additionally, an organization
may wish to capture details on internal APIs, service-layer applications and custom ETL processes.
Build
Once some volume of data is collected, applications can start to be categorized and materially
described with attribute values. Application catalogs can take many forms, from spreadsheets to
purpose-built database applications. The catalog may link to defect tracking systems, source code
repositories and security scanners. Regardless of what technology it’s built on, the catalog should be
relatively easy to use, update and query.
Attribute-wise, the application catalog should align with the enterprise's risk assessment framework.
Each entry in the application catalog should include at a minimum, the application name, application
owner, development team, and other stakeholders such as technical leads that would help with
incident response and vulnerability management. Include risk descriptors such as criticality, software
composition (e.g. key third-party libraries and platforms), number of users, environments installed,
platforms, languages, data sensitivities and compliance touchpoints. Descriptors will vary from one
organization to the next, but the intent is to equip users with enough information to make informed
risk-based decisions.
Run
Once an application catalog is in place, it should be leveraged to align enterprise security processes
and standards with actual security practices. The catalog, when integrated with the rest of the
secure SDLC program, will make evident when and where to perform software assurance activities,
how to prioritize security-related bug fixes, and enable security teams to measure progress over
time.
For example, an organization may choose to establish a policy that states, “High risk applications will
undergo a third-party penetration test annually.” The catalog should clearly identify “high risk
applications” while leaving no room for interpretation or argument.
Not all applications will require all security activities. For example, source code security analysis may
only be required of the most critical applications and for code changes touching authentication
controls. Secure architecture reviews may only be required of new mission-critical systems.
As you can see, the application catalog hooks into all aspects of the secure SDLC. It truly becomes
the system of record for the enterprise's application security program.
Secure SDLC Lesson 2: Assessment Toolchain
232 | P a g e
Most organizations would agree that maintaining a fast, predictable flow of planned work (e.g.
projects, scheduled changes) that achieves business goals while minimizing the impact of unplanned
work (e.g. bug fixes, outages) is the ultimate IT goal. Security assessment activities should be part of
planned work, and to accomplish that, the right tools must be selected. As an extension, the tools
must be properly configured and integrated into the secure SDLC program to truly be effective.
Plan
Multiple studies have shown that identifying and remediating security flaws as early as possible in
the development lifecycle is the least costly option. This is often referred to as “shifting security
left.” Enabling developers to run static code analysis tools from their IDEs to identify possible
security weaknesses is one common way to achieve the shift. The integration of dynamic, runtime
and interactive assessment tools into various pre-production stages of the SDLC is another common
approach.
That said, all tools are not created equal. SAST, DAST and IAST tools support a wide variety of serverside and client-side languages and frameworks. Some include features like incremental code
scanning and tunable rules. Others offer integration with build processes and defect tracking
systems. Consider separating must-haves vs. nice-to-haves, and if possible avoid vendor lock-in.
Also understand the capabilities and limitations of the tools in question. Get a feel for where the
gaps are and how to address them. There will be gaps, and it’s important to understand what they
are. Consider conducting tool bake-offs against a representative subset of your application code to
determine the suitability of each tool to your environment.
Build
Once tool selection is complete, and limitations/capabilities are identified, the next step is tool
configuration. This step is absolutely essential for minimizing the amount of false-positives while
maximizing code coverage. Consider that oftentimes a wide range of tools with overlapping
capabilities is necessary for complete or “manageable” coverage, and confidence that they’re
functioning as expected.
Identifying the right tools takes time and effort. Subject matter experts are usually necessary to help
vet and verify issues identified and tune rulesets. Scanners may not support legacy code, and
sometimes re-platforming is a less costly option. On the flip side, scanners can lag behind the latest
available frameworks and languages. In both cases, code quality tools and custom test scripts are
used to fill the gap in security capability, especially for teams doing continuous
integration/continuous deployment.
Run
Once the toolchain is operational, its output should obviously be consumed in some manner. For
instance, output from security scanners embedded in test and staging environments will typically
feed into defect tracking systems. Security issues caught earlier in the cycle may not. It’s important
though to consider recording the source/stage where each vulnerability was identified, and by what
tool. We will visit this question again when we talk about metrics.
233 | P a g e
Based on security thresholds defined in the SDLC security standards, security gates will be
implemented to break the build/release process when issues of a certain severity or higher are
identified by security tools. Additionally, because security testing may not be wired in series with the
release workflow, a process to address issues caught by parallel scans and out-of-band penetration
tests should be defined.
The end goal is to build a reliable and trustworthy toolchain with quality automated tools that gives
sufficiently wide coverage across the application portfolio. To fill the remaining gaps, manual testing
and other controls will be required.
Secure SDLC Lesson 3: Knowledge Management
The term “knowledge management” (KM) refers to using vulnerability mining to turn remediation
into lessons learned. Essentially this involves taking knowledge from security remediation activities
and placing it within a KM repository that developers, architects and other stakeholders can access.
By sharing remediation information across teams, an organization can remove or reduce intelligence
silos that contribute to recurring and familiar software bugs.
Plan
After performing applications assessments and other security testing activities for a time, there
should be enough remediation data within your defect tracking system to start pulling out the most
common security-related coding mistakes. This assumes that security-related bugs are flagged as
such. If your organization isn’t already flagging or tagging defects this way, now is the time to start.
Consider also mining qualifying bugs by feature or functional areas like authentication, and/or by
vulnerability types like lack of input validation. If possible, separate results by language and/or
platforms used. Some data normalization may be required to make this easier. Sort by the number
of bugs discovered in each category, and focus on documenting those areas first.
Build
Again, the end goal for building a KM solution is to store company-specific secure coding best
practices and remediation techniques as proactive guidance for development teams. A centralized,
accessible location such as a Wiki is well-suited for this task. Content typically will include links to
relevant security standards, sample code and design templates for things like tying an application’s
authentication into the corporate SSO. By defining coding standards around approved enterprise
architecture components (e.g. libraries, platforms), architects and developers can gain confidence
when developing on secure-by-default frameworks and patterns.
Alternatively, developers could dig into the bug tracking solution to find other examples of the bugs,
and see how they were fixed, but a curated central knowledge base is very effective. It takes time,
but it doesn’t cost product dollars, doesn’t interfere with the build cycle, and it saves a lot more time
later when other developers encounter similar issues.
234 | P a g e
Run
Operationally, someone has to take ownership of selecting and publishing this information. For
example, when a vulnerability is identified and remediated, a developer should draft up remediation
guidance and dump it into the KM solution. Leverage a workflow so a lead developer or other SME
can approve the content, make sure comments are adequate to describe the issue, what the
remediation was for, include example code, etc.
Teams should take advantage of the KM solution to proactively watch out for the same mistakes
other teams have made. Leverage things like tags, keywords and filters to make the pool of historical
knowledge searchable. In the end, the system provides developers assurance that if they’re
programming in a certain known-good way, they’re aligned with the organization’s definition of
secure development.
Implemented correctly, KM solutions serve as a continuous feedback loop that helps improve code
quality at the source. This is another great example of shifting security left, and as mentioned in an
earlier post in this series, that can mean significantly reducing both remediation costs and security
risk.
Secure SDLC Lesson 4: Metrics
As the secure SDLC program matures, vulnerabilities should be caught and remediated earlier in the
lifecycle. To know if the program is truly working, organizations must capture metrics. The specific
metrics chosen should support and align with the organization’s business objectives and risk
management program.
Plan
Security metrics related to the SDLC are best captured at security checkpoints. These checkpoints or
gates may include in-IDE static analysis, code commit analysis, build-time static-analysis, manual
code review, dynamic scanning in QA/integration test, and pre- and post-production penetration
testing. Internal and external bug bounty programs may also be included as post-production options.
By capturing which checkpoint or tool was used to discover which security defects, you will be able
to track trends across your application portfolio. In theory, as the secure SDLC program matures,
more security bugs should be caught early in the software lifecycle. This metric will help verify this in
practice.
In addition, proper metrics will help identify toolchain issues, or conversely, justify their expense. For
example, if your static analysis tools fail to capture security defects that surface during penetration
testing, then there may be a problem in code coverage or a scanner ruleset.
Build
Beyond tracking the discovery point, there are two main classes of key performance indicators
(KPIs): efficiency and risk (though some indicators may fall in the gray area between).
235 | P a g e
Each KPI may be filtered by vulnerability type, development team or business area, phase of SDLC
discovered, etc., and is often reported per time period.
Efficiency indicators may already be available in your bug tracking system. These may include:





Time to Remediate (TTR) – how long between when a specific vulnerability is first identified
and when it’s fully remediated
Average TTR – TTR per time period
Current/Average Remediation Queue Size – how much technical security debt exists
Velocity – bug fixes completed per time period
Pipeline Stress – how many requests for things like manual testing or code review were
expedited
Other indicators can be designed to track efficiency in security operations, like time to assign an
AppSec resource for internal assurance services, time to complete and so on.
Risk indicators describe areas specific to the confidentiality, integrity and availability of applications.






Coverage – the number of applications per assurance activity (code scan, dynamic analysis)
per time period; applications can be ranked according to risk or mission criticality
Top Vulnerability Types – per time period
Rate of Recurrence – how often known defects come back
Churn – how many times a specific vulnerability was incorrectly remediated
Composite Risk Rating – often shown graphically, this is a somewhat arbitrary visualization
of business risk, defined by something similar to: vulnerability severity x defect count x
application risk rating
Security Defect Ratio - number of security defects divided by the total number of defects
These metrics are usually presented on some form of dashboard, usually with capabilities for drill
down and trend reporting. Remember though that the technologies used to implement KPIs are
much less important than the information they’re intended to convey. Avoid developing KPIs and
visualizations that bring no value to your secure SDLC program.
Run
Over time, there should be a reduction in post-release vulnerabilities, which again are the most
costly to remediate and pose the most risk to the organization. Expect a downward trend in bugs
caught later in the SDLC as the program matures. Additionally, vulnerabilities discovered in-cycle
should be remediated more quickly. When unexpected indicator values are observed, root cause
analysis is often required to address the issue. For example, if severe vulnerabilities continue to be
found by an external bug bounty program, then clearly something upstream isn’t working.
Properly designed metrics provide a great way to measure the effectiveness of the secure SDLC
program over time, and also provide useful feedback when aspects of the program are tweaked.
Capturing key indicators affords organizations the ability to experiment with new vendor tools and
alternate approaches to testing, and to determine the impact of different types and sources for
developer training.
236 | P a g e
In short, metrics can take much of the guesswork out of knowing how well your secure SDLC
program is working.
Secure SDLC Lesson 5: Personnel
It’s no secret that finding and retaining dependable, well-trained application security professionals is
a serious challenge, and has been for years. Part of the problem is that the breadth and depth of
AppSec knowledge is rather astronomical; one could argue that it’s exponentially wider than
network security and grows at a much faster rate. Based on what I’ve seen, teams tend to be
perpetually short-staffed and undertrained.
Furthermore, many companies struggle with how best to build out their AppSec capabilities. Should
application scanning and testing activities funnel through an AppSec team, or should developers be
able to launch scans on demand and only engage AppSec SMEs when needed? How much and what
pieces of the secure SDLC program should be outsourced?
Plan
Considering the current state of things, there is a tendency for organizations, especially those
following Agile and DevOps principles, to have an over-reliance on automated security tools. It’s
really no wonder that severe security issues still make it to production today. When secure SDLC
programs are built too heavily on technology and too thin on trained professionals, they set
themselves up for real trouble.
In a recent client discussion regarding security policies and standards, one stakeholder admitted
their mantra was, “Tools, not rules!” My response was, “That’s great. Now show me how closely
your tools align with your security requirements.” The reality is that automated tools have
limitations, and relying on them too much is analogous to organizations trying to outsource risk to
third-party providers. It’s misplaced trust. The point here is tools are no substitute for skilled subject
matter experts, which in turn are absolutely essential to a successful secure SDLC program.
Build
Just as point-and-click scanners alone are insufficient, leaning too much on too few individuals can
lead to constraints and, even worse, burn-out. One way to address the resource shortage is to “train
up” more developers into AppSec.
Unfortunately, finding sources of relevant, comprehensive, professional grade AppSec training is
relatively difficult these days. There are many options, from onsite/offsite ILT and on-demand CBT to
online webinars and videos. However, as it turns out, developers (and many existing security
professionals) actually tend to learn best though more informal sources like blogs, feeds and similar
online sources. Consider integrating some of these non-standard sources into the training
curriculum.
Additionally, training folks in offensive security can help them code defensively. Again, there are a
multitude of choices available, but no single source that would be considered comprehensive.
Consider compiling a list of resources that best fit your teams’ needs and are tailored for each role.
237 | P a g e
Run
Knowing if your organization has the right personnel in the right places can be made evident through
secure SDLC metrics, as mentioned earlier in this blog series. It can also be measured by observing
how much your teams are leveraging your knowledge management solution.
Ongoing training should not be neglected. Plan for periodic refresher courses, and consider
incorporating training and even certifications into role-specific performance plans. As application
security is such a moving target, recurring training just makes sense anyway.
Though developers tend to get security concepts, they still struggle with connecting conceptual
knowledge to prescriptive secure coding practices. By building out your organization’s AppSec
capabilities through talent acquisition, training and skills development, you will be well equipped to
help them bridge that gap.
Conclusion
Secure SDLC programs tend to be unique to each organization. Application catalogs, assessment
toolchains, knowledge management solutions and metrics may be similar from one company to the
next, but will often be implemented on vastly disparate technologies. Organizational structure,
culture, industry, and many other determining factors will influence how you ultimately develop and
implement a secure SDLC program that is truly your own.
Activity 11
Why are lessons learned documented?
238 | P a g e
Activity 11
239 | P a g e
Activity 11
Collect, analyse and report performance measures
Ensuring system security can seem an overwhelming job, given the complexity of technologies, the
wealth of new applications continually entering the marketplace, and the growing number of attacks
on corporations from external intruders.
You will never too able to provide perfect security for your organization. However, you can
significantly improve security, and save a great deal of time and effort along the way, by marrying
security to every phase of the SDLC.
As a part of any organizations well defined SDLC process, the development of documentation
specific to the system should be outlined. The documentation would outline the system from
development to its’ production state. The documentation may include items identified below37.
• system functional requirements,
37
Source: SANS, as at https://www.sans.org/reading-room/whitepapers/awareness/facets-informationsecurity-program-1343, as on 10th May, 2017.
240 | P a g e
• database software configurations,
• data dictionary,
• operating system configurations,
• user application configuration,
• system architecture (physical),
• data flow (logical),
• system interconnections,
• user manuals,
• system security plan,
• a disaster recovery/business continuity plan,
• security test plan,
• certification statement, and
• any service level agreements, memorandums of understanding, or memorandums of agreement
that was required for the system.
The documentation will support the organizations information security program through its
availability allowing authorized and qualified individuals the ability to understand the system
configurations and operational state. This assists problem isolation reducing system downtime and
provides a baseline for the development of enhancements for the system in the future. Having the
right documentation available keeps an organization from depending on the individual(s) who
developed the system. The system owner is the party responsible to ensure that the documentation
is developed, maintained, and made available to the appropriate people.
Activity 12
During which stage of the software development life cycle should security be implemented?
(a) Development
(b) Project initiation
(c) Deployment
241 | P a g e
Activity 12
(d) Installation
In which software development life cycle phase do the programmers and developers become
deeply involved and do the majority of the work?
(a) System Design Specifications
(b) Software Development
(c) Operation and Maintenance
(d) Functional Design Analysis and Planning
Which of the following is a valid system development methodology?
(a) The spring model
(b) The spiral model
(c) The production model
(d) The Gantt model
What is the process of cataloging all versions of a component configuration called?
(a) The configuration library
(b) The component library
(c) The catalog database
(d) The software component library
242 | P a g e
Information Technology
ICTNWK510 Develop, implement and evaluate system
and application security
ICTNWK510 DEVELOP, IMPLEMENT AND EVALUATE
SYSTEM AND APPLICATION SECURITY
Develop system and
application security
Implement system and
application security
Evaluate system and
application security
1
2
SIX PHASES OF THE SYSTEM
DEVELOPMENT LIFE CYCLE
SYSTEM
DEVELOPMENT
LIFE CYCLE (SDLC)
• Preliminary Investigation
• Assesses feasibility and practicality of system
• System Analysis
• Study old system and identify new requirements
• Defines system from user's view
• System Design
• Design new/alternative system
• Defines system from technical view
3
4
SDLC PHASES
SIX PHASES OF THE SYSTEM
DEVELOPMENT LIFE CYCLE
Preliminary
Investigation
• System Development
• New hardware and software is acquired, developed, and tested
System
Analysis
System Operation
& Maintenance
• System Implementation
• System installation and training
• System Operation & Maintenance
System
Implementation
n
• Daily operation
System
Design
• Periodic evaluation and updating
5
System
Development
6
PHASE 2:
SYSTEM ANALYSIS
PHASE 1:
PRELIMINARY INVESTIGATION
• Determine if a new system is needed
• In depth study of the existing system to
determine what the new system should do.
• Three primary tasks:
• Expand on data gathered in Phase 1
• Define the problem
• By observation and interview, determine what information is
needed by whom, when, where and why
• Suggest alternative solutions
• Prepare a short report
7
• In addition to observation and interviews,
examine:
• Formal lines of authority (org chart)
• Standard operating procedures
• How information flows
• Reasons for any inefficiencies
8
PHASE 2: SYSTEM ANALYSIS
DOCUMENTATION PRODUCED
PHASE 2: SYSTEM ANALYSIS
TOOLS USED
• Checklists - list of questions
• Top-down analysis - start with top level
components, break down into smaller parts
through each successive level
• Complete description of current system and its
problems
• Requirements for for new system including:
• Subject
• Grid charts - to show relationship between
inputs and outputs
• Scope
• System flowcharts - charts flow of input data,
processing, and output which show system
elements and interactions
• Benefits
9
• Objectives
10
• Possible development schedule
PHASE 3:
SYSTEM DESIGN
PHASE 3: SYSTEM DESIGN
TOOLS USED
• Uses specifications from the systems analysis
to design alternative systems
• Computer-Aided Software Engineering (CASE)
tools are software-based products designed to help
automate the production of information systems.
• Evaluate alternatives based upon:
• Examples:
• Economic feasibility - Do benefits justify costs?
• Technical feasibility - Is reliable technology
and training available?
• Operational feasibility - Will the managers and
users support it?
11
•
•
•
•
•
•
Diagramming Tools
Data Repositories
Prototyping Tools
Test Data Generators
Documentation Tools
Project Management Tools
12
PHASE 3: SYSTEM DESIGN
DOCUMENTATION PRODUCED
PHASE 4:
SYSTEM DEVELOPMENT
• Build the system to the design specifications
• System Design Report
• Develop the software
• Describe Alternatives including:
• Purchase off-the-shelf software OR
• Write custom software
• Inputs/Outputs
• Processing
• Storage and Backup
• Acquire the hardware
• Test the new system
• Recommend Top Alternative based upon:
• System Fit into the Organization
• Flexibility for the future
• Costs vs. benefits
• Module (unit) test - tests each part of system
• Integration testing - tests system as one unit
• Create manuals for users and operators
13
14
PHASE 5: SYSTEM IMPLEMENTATION
TYPES OF CONVERSION
PHASE 5:
SYSTEM IMPLEMENTATION
• Direct/plunge/crash approach – entire new system
completely replaces entire old system, in one step
• Convert from old system to new system
• Parallel approach - both systems are operated side by
side until the new system proves itself
• Train users
• Pilot approach - launched new system for only one
group within the business -- once new system is
operating smoothly, implementation goes company-wide
• Compile final documentation
• Evaluate the new system
• Phased/incremental approach - individual parts of new
system are gradually phased-in over time, using either
crash or parallel for each piece.
16
15
PHASE 5: SYSTEM
IMPLEMENTATION
PHASE 6: OPERATIONS &
MAINTENANCE
• Types of changes:
• User Training
•
•
•
•
•
• Ease into system, make them comfortable, and gain their support
• Most commonly overlooked
• Can be commenced before equipment delivery
• Outside trainers sometimes used
17
Physical repair of the system
Correction of new bugs found (corrective)
System adjustments to environmental changes
Adjustments for users’ changing needs (adaptive)
Changes to user better techniques when they become available
(perfective)
18
DELIVERABLES OF THE SDLC
PHASE 6: OPERATIONS &
MAINTENANCE
Approved Feasibility
Study
Preliminary
Investigation
• Evaluation Methods
Problem
Specifications
System
Analysis
• Systems audit - performance compared to original specifications
System
Design
• Periodic evaluation - “checkups” from time to time, modifications
if necessary
Abort Project
Goto next phase
Goto Previous phase
Design Specifications
System
Development
Begin building
new system
Coded and
Tested System
System
Implementation
System converted
Users trained
System
Maintenance
Operational System
Documentation completed
19
20
Bespoke Applications Vs. Commercial Applications
Application Development internal use:
• Bespoke, customized, one-off application
•Audience is not so great: (Users, developers, test)
Vulnerabilities are not discovered too quickly by users.
Vulnerabilities are discovered by hackers, they actively look for
them.
INTEGRATION INTO THE SDLC
(SOFTWARE DEVELOPMENT LIFE
CYCLE)
21
Bespoke Applications Vs. Commercial Applications
22
COMPLEXITY VS SECURITY
Bespoke application = Small audience = Less chance of vulnerabilities
being discovered
This is unlike, Say Microsoft XP 210 Million copies sold (http://www.forbes.com/
As Functionality and
May2004)
increase security
hence complexity
First Line of Defense:
decreases.
Integrating security into
functionality at design time
Is easier and cheaper.
The Developer:
•Writes the code.
•Understands the problem better
than anyone!
•Has the skill set.
•More effective and efficient in
providing a solution
“100 Times More Expensive to Fix Security
Bug at Production Than Design”
– IBM Systems Sciences Institute
23
It also costs less in the long-term.
-maintenance cost
24
A FEW FACTS AND FIGURES:
GROWTH OF THREAT:
GROWTH IN THE
TOOLS AVAILABLE.
How Many Vulnerabilities Are Application Security Related?
25,000
Hacker Tools
20,000
15,000
10,000
5,000
Categories:
• Binder
• Carding
• Cracking Tool
• Flooder
• Key Generator
• Mail Bomber
• Mailer
• Misc Tool
• Nuker
• Packer
• Password Cracker
• Password Cracking Word List
• Phreaking Tool
• Port Scanner
• Probe Tool
• Sniffer
• Spoofer
• Trojan
• Trojan Creation Tool
• Virus Creation Tool
• Virus Source
• Virus Tutorial
• War Dialer
19
80
19
81
19
82
19
83
19
84
19
85
19
86
19
87
19
88
19
89
19
90
19
91
19
92
19
93
19
94
19
95
19
96
19
97
19
98
19
99
20
00
20
01
20
02
20
03
20
04
0
Year
25
Source: PestPatrol.com26
A FEW FACTS AND FIGURES
(CONTD)
IF CARS WERE BUILT LIKE
APPLICATIONS….
• Interesting Statistics – Employing code review
• IBM Reduces 82% of Defects Before Testing Starts
• HP Found 80% of Defects Found Were Not Likely To Be Caught in
Testing
• 100 Times More Expensive to Fix Security Bug at Production Than
Design”
– IBM Systems Sciences Institute
• Promoting People Looking at Code
1.
70% of all cars would be built without following the original designs
and blueprints.The other 30% would not have designs.
2.
Car design would assume that safety is a function of road design and
that all drivers were considerate, sober and expert drivers.
3.
Cars would have no airbags, mirrors, seat belts, doors, roll-bars, sideimpact bars, or locks, because no-one had asked for them. But they
would all have at least six cup holders.
4.
5.
Not all the components would be bolted together securely and many of
them would not be built to tolerate even the slightest abuse.
Safety tests would assume frontal impact only. Cars would not be roll
tested, or tested for stability in emergency maneuvers, brake
effectiveness, side impact and resistance to theft.
6.
Many safety features originally included might be removed before the
car was completed, because they might adversely impact performance.
• Improvement Earlier in SDLC
• Fix at Right Place; the Source
• Takes 20% extra time – payoff is order of magnitude more.
28
27
- Denis Verdon
Ref: http://ganssle.com/Inspections.pdf
HOW DO WE DO IT?
IF CARS WERE BUILT LIKE
APPLICATIONS….
7.
70% of all cars would be subject to monthly recalls to add major
components left out of the initial production. The other 30% wouldn’t
be recalled, because no-one would sue anyway.
8.
The after-market for safety devices would include such useful products
as training wheels, screen doors, elastic seatbelts and devices that
would restrict the car’s top speed to 3mph, if found to be unsafe (which
would be always).
9.
Useful safety could be found, but could only be custom retro-fitted,
would take six months to fit and would cost more than the car itself.
10. A NCT/MOT inspection would consist of counting the wheels and
making recommendations on wheel quantity.
11. Your only warning indicator would be large quantities of smoke and
flame in the cab.
12. You could only get insurance from one provider, it would be extremely
expensive, require a duplicate NCT/MOT inspection, and you might still
never be able to claim against the policy.
- Denis Verdon
29
• Security Analyst:
• Get involved early in SDLC. Security is a function of the asset we
want to secure, what's it worth?
• Understanding the information held in the application and the
types of users is half the battle.
• Involve an analyst in the design phase and thereafter.
• Developer:
• Embrace secure application development. (Educate)
• Quality is not just “Does it work” Security is a measure of quality
also.
30
Software security tollgates in the SDLC
HOW DO WE DO IT? (CONTD)
Iterative approach
• QA:
•
Security vulnerabilities are to be considered bugs, the
same way as a functional bug, and tracked in the same
manner.
Security
requirements
Risk
analysis
• Managers:
Static
analysis
(tools)
Design
Review
Penetration
testing
Risk-based
security tests
• Factor some time into the project plan for security.
• Consider security as added value in an application.
– $1 spent up front saves $10 during development and $100
after release
31
Requirements
and use cases
Design
Test plans
Code
Test
results
Field
feedback
Code
Review
APPLICATION SECURITY RISK
CATEGORIZATION
APPLICATION SECURITY
PROJECT PLAN
• Goal
• Define the plan to ensure security at the end
• More security for riskier applications
• Ideally done at start of project
• Ensures that you work the most critical issues first
• Can also be started before or after development is complete
• Scales to hundreds or thousands of applications
• Based on the risk category
• Tools and Methodology
• Identify activities at each phase
• Security profiling tools can gather facts
• Necessary people and expertise required
• Size, complexity, security mechanisms, dangerous calls
• Who has responsibility for risks
• Questionnaire to gather risk information
• Ensure time and budget for security activities
• Asset value, available functions, users, environment, threats
• Risk-based approach
32
33
• Establish framework for establishing the “line of sight”
34
• Evaluates likelihood and consequences of successful attack
APPLICATION SECURITY
REQUIREMENTS TAILORING
• Get the security requirements and policy right
DESIGN REVIEWS
• Better to find flaws early
• Security design reviews
• Start with a generic set of security requirements
•
•
•
•
Must include all security mechanisms
Must address all common vulnerabilities
Can be use (or misuse) cases
Should address all driving requirements (regulation, standards,
best practices, etc.)
• Check to ensure design meets requirements
• Also check to make sure you didn’t miss a requirement
• Assemble a team
• Experts in the technology
• Security-minded team members
• Tailoring examples…
• Specify how authentication will work
• Detail the access control matrix (roles, assets, functions,
permissions)
• Define the input validation rules
• Choose an error handling and logging approach
35
• Do a high-level penetration test against the design
• Be sure to do root cause analysis on any flaws identified
36
SOFTWARE VULNERABILITY
ANALYSIS
APPLICATION SECURITY
TESTING
• Find flaws in the code early
• Identify security flaws during testing
• Many different techniques
• Static (against source or compiled code)
• Security focused static analysis tools
• Develop security test cases
• Peer review process
• Based on requirements
• Formal security code review
• Be sure to include “negative” tests
• Dynamic (against running code)
• Scanning
• Test all security mechanisms and common vulnerabilities
• Penetration testing
• Goal
• Ensure completeness (across all vulnerability areas)
37
• Ensure accuracy (minimize false alarms)
APPLICATION SECURITY DEFECT
TRACKING AND METRICS
• “Every security flaw is a process problem”
• Flaws feed into defect tracking and root cause
analysis
38
CONFIGURATION MANAGEMENT
AND DEPLOYMENT
• Ensure the application configuration is secure
• Tracking security defects
• Find the source of the problem
• Bad or missed requirement,design flaw, poor implementation, etc…
• Security is increasingly “data-driven”
• XML files, property files, scripts, databases, directories
• ISSUE: can you track security defects the same way as other defects
• How do you control and audit this data?
• Metrics
• What lifecycle stage are most flaws originating in?
• What security mechanisms are we having trouble implementing?
• What security vulnerabilities are we having trouble avoiding? 39
• Design configuration data for audit
• Put all configuration data in CM
• Audit configuration data regularly
• Don’t allow configuration changes in the field
40
WHAT NOW?
"So now, when we face a choice between
adding features and resolving security
issues, we need to choose security."
-Bill Gates
The user's going to pick dancing pigs over security every time.
-Bruce Schneier
If you think technology can solve your security
problems, then you don't understand the problems
and you don't understand the technology.
-Bruce Schneier
Using encryption on the Internet is the equivalent of arranging
an armored car to deliver credit-card information from someone
living in a cardboard box to someone living on a park bench.
-Gene Spafford 41
THE SECURITY SYSTEMS
DEVELOPMENT LIFE CYCLE
(SECSDLC)
42
THE SECURITY SYSTEMS
DEVELOPMENT LIFE CYCLE
(SECSDLC)
INVESTIGATION IN THE
SECSDLC
• May differ in several specifics, but overall methodology is
similar to the SDLC
• SecSDLC process involves:
• Often begins as directive from management specifying the
process, outcomes, and goals of the project and its budget
• Frequently begins with the affirmation or creation of security
policies
• Teams assembled to analyze problems, define scope, specify
goals and identify constraints
• Identification of specific threats and the risks that they represent
• Subsequent design and implementation of specific controls to
counter those threats and assist in the management of the risk
those threats pose to the organization
• Feasibility analysis determines whether the organization has
resources and commitment to conduct a successful security
analysis and design
44
43
ANALYSIS IN THE SECSDLC
RISK MANAGEMENT
• A preliminary analysis of existing security policies or
programs is prepared along with known threats and current
controls
• Risk Management: process of identifying, assessing, and
evaluating the levels of risk facing the organization
• Includes an analysis of relevant legal issues that could affect
the design of the security solution
• Specifically the threats to the information stored and processed
by the organization
• To better understand the analysis phase of the SecSDLC, you
should know something about the kinds of threats facing
organizations
• In this context, a threat is an object, person, or other entity that
represents a constant danger to an asset
• Risk management begins in this stage
45
KEY TERMS
46
THREATS TO INFORMATION
SECURITY
• Attack: deliberate act that exploits a vulnerability to achieve
the compromise of a controlled system
• Accomplished by a threat agent that damages or steals an
organization’s information or physical asset
• Exploit: technique or mechanism used to compromise a system
• Vulnerability: identified weakness of a controlled system in
which necessary controls are not present or are no longer
effective
47
48
RISK MANAGEMENT
SOME COMMON ATTACKS
• Use some method of prioritizing risk posed by each
category of threat and its related methods of attack
• Malicious code
• Spoofing
• Hoaxes
• Man-in-the-middle
• Back doors
• Spam
• Password crack
• Mail bombing
• Brute force
• Sniffer
• Dictionary
• Social engineering
• Denial-of-service (DoS) and
distributed denial-of-service
(DDoS)
• Buffer overflow
• To manage risk, you must identify and assess the value
of your information assets
• Risk assessment assigns comparative risk rating or
score to each specific information asset
• Risk management identifies vulnerabilities in an
organization’s information systems and takes carefully
reasoned steps to assure the confidentiality, integrity,
and availability of all the components in organization’s
information system
• Timing
50
49
SECURITY MODELS
DESIGN IN THE SECSDLC
• Security managers often use established security models to
guide the design process
• Design phase actually consists of two distinct phases:
• Logical design phase: team members create and develop a
blueprint for security, and examine and implement key policies
• Physical design phase: team members evaluate the technology
needed to support the security blueprint, generate alternative
solutions, and agree upon a final design
• Security models provide frameworks for ensuring that all areas
of security are addressed
• Organizations can adapt or adopt a framework to meet their
own information security needs
52
51
POLICY
SETA
• A critical design element of the information security program
is the information security policy
• Another integral part of the InfoSec program is the security
education and training program
• Management must define three types of security policy:
• SETA program consists of three elements: security education,
security training, and security awareness
• General or security program policy
• Purpose of SETA is to enhance security by:
• Issue-specific security policies
• Improving awareness
• Systems-specific security policies
• Developing skills and knowledge
• Building in-depth knowledge
53
54
DESIGN
MANAGERIAL CONTROLS
• Attention turns to the design of the controls and safeguards
used to protect information from attacks by threats
• Address the design and implementation of the security
planning process and security program management
• Three categories of controls:
• Management controls also address:
• Managerial
• Risk management
• Operational
• Security control reviews
• Technical
55
56
OPERATIONAL CONTROLS
TECHNICAL CONTROLS
• Cover management functions and lower level planning
including:
• Address those tactical and technical issues related to
designing and implementing security in the organization
• Disaster recovery
• Incident response planning
• Technologies necessary to protect information are examined
and selected
• Operational controls also address:
• Personnel security
• Physical security
• Protection of production inputs and outputs
57
58
CONTINGENCY PLANNING
PHYSICAL SECURITY
• Essential preparedness documents provide contingency
planning (CP) to prepare, react and recover from
circumstances that threaten the organization:
• Physical Security: addresses the design, implementation, and
maintenance of countermeasures that protect the physical
resources of an organization
• Physical resources include:
• Incident response planning (IRP)
• People
• Disaster recovery planning (DRP)
• Hardware
• Business continuity planning (BCP)
• Supporting information system elements
59
60
IMPLEMENTATION IN THE
SECSDLC
INFOSEC PROJECT TEAM
• Security solutions are acquired, tested, implemented, and tested again
• Should consist of individuals experienced in one or multiple
technical and non-technical areas including:
• Personnel issues are evaluated and specific training and education
programs conducted
• Perhaps most important element of implementation phase is
management of project plan:
• Champion
• Team leader
• Security policy developers
• Risk assessment specialists
• Planning the project
• Security professionals
• Supervising tasks and action steps within the project
• Systems administrators
• Wrapping up the project
• End users
62
61
STAFFING THE INFOSEC
FUNCTION
•
INFOSEC PROFESSIONALS
Each organization should examine the options for staffing of
the information security function
1.
Decide how to position and name the security function
2.
Plan for proper staffing of information security function
3.
Understand impact of information security across every role in
IT
4.
Integrate solid information security concepts into personnel
management practices of the organization
• It takes a wide range of professionals to support a diverse
information security program:
• Chief Information Officer (CIO)
• Chief Information Security Officer (CISO)
• Security Managers
• Security Technicians
• Data Owners
• Data Custodians
• Data Users
64
63
CERTIFICATIONS
MAINTENANCE AND CHANGE IN
THE SECSDLC
• Many organizations seek professional certification so that they
can more easily identify the proficiency of job applicants:
• CISSP
• SSCP
• Once information security program is implemented, it must be
operated, properly managed, and kept up to date by means of
established procedures
• GIAC
• SCP
• If the program is not adjusting adequately to the changes in the
internal or external environment, it may be necessary to begin
the cycle again
• ICSA
• Security +
• CISM
65
66
MAINTENANCE MODEL
ISO MANAGEMENT MODEL
• While a systems management model is designed to manage
and operate systems, a maintenance model is intended to
focus organizational effort on system maintenance:
• One issue planned in the SecSDLC is the systems management
model
• ISO management model contains five areas:
• External monitoring
• Fault management
• Internal monitoring
• Planning and risk assessment
• Configuration and name management
• Vulnerability assessment and remediation
• Accounting management
• Readiness and review
• Performance management
• Vulnerability assessment
• Security management
67
SECURITY MANAGEMENT
MODEL
68
SECURITY PROGRAM
MANAGEMENT
• Fault Management involves identifying and addressing faults
• Configuration and Change Management involve administration
of components involved in the security program and
administration of changes
• Accounting and Auditing Management involves chargeback
accounting and systems monitoring
• Performance Management determines if security systems are
effectively doing the job for which they were implemented
• Once an information security program is functional, it must be
operated and managed
• In order to assist in the actual management of information
security programs, a formal management standard can provide
some insight into the processes and procedures needed
• This could be based on the BS7799/ISO17799 model or the
NIST models described earlier
69
70
RISK ASSESSMENT
RISK ASSESSMENT
• The risk assessment process - converting subjective
risks into objective harms.
• Determining the level of risk is achieved by
comparing the relationship between the threats to
information and assets and the known security
weaknesses or vulnerability of
information
technology systems.
Harms to your information system can be assessed,
analysed and measured.
Risk is assessed against the likelihood and consequence
of compromising:
• Confidentiality
• The level of acceptable risk is a managerial decision
based on the information and recommendations
provided in the risk assessment.
• Integrity
• Availability of your information
71
72
RISK ASSESSMENT
RISK ASSESSMENT
Discover environmental data:
• Establish the Context
• What data do you hold?
• Define relationship with other systems.
• Where is the information?
• Identify assets.
• Where does the data reside ?
• Establish risk criteria.
• Interfaces ?
• Risk Identification
• Who has access to your information?
• Identify the risks to be managed.
• What are the boundaries of your system?
• Determine what to protect against (Threats).
• Determine who to protect against.
• Is information systems security about
computers or Information ?
73
74
RISK ASSESSMENT
RISK ASSESSMENT
• Risk Analysis
• Risk Evaluation and Treatment
• Analyze risks to be managed.
• Compare assessed risks against risk criteria.
• Estimate likelihood and consequence.
• Consider treatment options.
• Determine context against management/control measures.
• Assess existing/proposed security measures.
• Recommendations
• Determine vulnerability and acceptable risk.
• Identify the steps to be taken to manage the accepted
or residual risks.
75
76
HIGH SECURITY
ENVIRONMENTS
HIGH SECURITY
ENVIRONMENTS
• Characterized by robust security plans.
• Information Security principles are the key.
• “The Need to Know” Principle.
• “The availability of information limited to those who
need to use or access the information to do their work”.
77
78
HIGH SECURITY
ENVIRONMENTS
SECURITY IN DEPTH
• Awareness - expectations about use and care of
information.
• Protective security procedures and measures must
be understood by those who will implement and
practice them.
• Concept of Security in Depth is a key
element in securing information in high
security environments.
• Several Protective Security barriers to
access information must be penetrated by
an external intruder or unauthorized staff
member with no “Need to Know”.
• Concept of “Security in Depth”
80
79
SECURITY IN DEPTH
SECURITY IN DEPTH
Protective Security procedures / measures:
• The barriers consist of interlocking measures
designed
to
combine
to
exclude
any
unauthorized penetration attempt.
• Protective Security procedures and measures
must be understood by those who will implement
and practice them.
81
THREATS TO INFORMATION
ASSETS
•
Staff background checks
•
Security instructions
•
Security education programs
•
Security guards
•
Access control and surveillance systems
•
Keys
•
Safes
•
Passwords
82
THREATS TO INFORMATION
ASSETS
Threats that can impact on the Confidentiality, Integrity
and Availability of an Information System include the
following generic threats:
• Accidental Threats
83
•
Fire
•
Programming error
•
Technical (hardware) failure
•
Data entry error
•
Environmental
•
Failure of power
84
COMPLIANCE OBLIGATIONS
THREATS TO INFORMATION
ASSETS
• Handle all information with care – all information
that an employee or contractor accesses must be
handled according to policy – official information,
personal information (Privacy Act).
• Deliberate Threats including:
• Denial of Service
• Eavesdropping
• Information must only be used for the purpose
stated by the agency or organization- any other use
is misuse.
• Malicious code – virus
• Malicious code - logic
• Malicious destruction of data
• Information must be secured appropriately- sound
security risk management – Procedures to identify
Vital information and information resources.
• Malicious destruction of Facilities
• Unauthorised access to data
• Unauthorised release of data
86
85
COMPLIANCE OBLIGATIONS
• Risks must be reduced to an acceptable level.
INFORMATION SECURITY PLANS
• The Integrity and reliability of information systems which
process, store or transmit information - require some level of
protection.
• If you can’t map your system you can’t secure your
data.
• Your system is bounded by your data model.
• What do you protect ?
• Some Government information (official information) is given
a security classification where its compromise could cause
harm to the nation, the public interest, the Government or
other entities or individuals.
• The data in the system.
• The system is more that the static ICT elements:
• Paper
• Media – removable
• Knowledge – people
• Specific security measures must be followed.
• Communications – internet, phone, mobile fax etc
87
88
INFORMATION SECURITY PLANS
INFORMATION SECURITY PLANS
Aim: Provide an effective, integral and available information
system and resource by:
Development of Information Security Plans requires a good
understanding of your data.
• Incorporating security into every facet of the architecture,
design and operation of the System environment.
• Step 1 Understand your information (Data)
• Step 2 Understand your Information System.
• Establishing a Security Management Strategy.
• Step 3 Map your system boundaries
Architecture and Policy Plan)
• Developing Security Standards.
89
- SAPP (Security
90
INFORMATION SECURITY PLANS
INFORMATION SECURITY PLANS
• Step 4 Develop an Information Security (IS) Policy.
• Implement Security System.
• Step 5 Develop an Information Security (IS) Plan.
• Implement compliance management system.
• Step 6 Develop and implement Risk Management System.
• Implement Security Education and Awareness Program
Outcome
• Step 7 Establish an IS Education Program.
Protecting information against unauthorized disclosure,
fraud, loss, damage or theft.
91
SECURITY PLANNING
92
SECURITY PLANNING
• A security plan must address the following
• A security plan
• Document describing how an organization addresses its security
needs
• Periodically reviewed and revised
• Creating a security plan
• Policy
• Current security state
• Recommendations and the requirements to meet the
security goals
• Accountability
• Who is responsible for a each security activity
• What it should do
• Timetable
• Who should write the plan
• For different security functions
• How to acquire support for the plan
• Continuing attention for periodic update
93
POLICY
94
INFORMATION SECURITY
PROGRAM
• Should address
• Who should be allowed to access what resources and how should
the access be regulated
Links in the Security Chain: Management, Operational, and Technical Controls
• Should specify
• Organizational security goals
• Where the responsibility lies (accountability policy); limits of
responsibility
• Organizational support for security
• Legal and ethical aspects?
95
 Risk assessment
 Security planning
 Security policies and procedures
 Contingency planning
 Incident response planning
 Security awareness and training
 Physical security
 Personnel security
 Certification, accreditation, and
security assessments
 Access control mechanisms
 Identification & authentication mechanisms
(Biometrics, tokens, passwords)
 Audit mechanisms
 Encryption mechanisms
 Firewalls and network security mechanisms
 Intrusion detection systems
 Security configuration settings
 Anti-viral software
 Smart cards
Adversaries attack the weakest link…where is yours?
96
CURRENT SECURITY STATE
RECOMMENDATION AND
REQUIREMENTS
• Can be determined on the basis of risk analysis
• It is important to
• Indicates
• Indicate what requirements are to be imposed in a plan, and over
what period
• Phase out implementation, and indicate elements of each phase
and their time periods
• Organizational assets
• Security threats to these assets
• Controls in place against these threats
• The plan
• Must be extensible
• Must include a procedure for change and growth
• Should remain laregely intact through change in the organization
97
98
RESPONSIBILITY FOR
IMPLEMENTATION
• Identify
people/groups
implementation
responsible
TIMETABLE AND
CONTINUING ATTENTION
for
• Timetable
• Expensive and complicated controls need gradual adoption
• A plan of accountability
• Some examples
• Training staff on new controls
• Personal computer users are responsible for their own
machine
• Project leaders for data and computations
• Database administrators – access and integrity of data
in databases
• Information officers for creation and use of data, and
retention and disposal of data
• Personnel staff members – responsible for security
involving employees
• Continuing attention
• Timely review and reevaluation
• Update object inventory and list of controls
• Review risk analysis to accommodate for parameters that may
change
99
100
COMMITMENT TO PLAN
PLANNING TEAM
• Size
• Acceptance of plan
• Depends on the complexity of organization and the degree
of commitment to security
• Organizational behavior studies show optimum size of a
working committee: 5 – 9
• Larger committee as oversight body
• Committee membership should be from each of the
following
• Hardware group
• Systems/applications programmers
• Indicate accountability,
• time for accomplishment,
• continuing reevaluation, etc.
• Education and publicity to help people understand
and accept security plan
• Management commitment depends on
• Encryption, protocols, security in OS and networks require
systems programming staff
• Data entry personnel
• Physical security personnel
• Representative users
• Needs a concise, well-organized report that includes a plan
of implementation and justification of costs
101
• Understanding cause and potential effects of lack of
security (Risk analysis)
• Cost-effectiveness of security plan
102
• Presentation of the plan
ATTRIBUTES OF GOOD POLICIES
ORGANIZATIONAL SECURITY
POLICIES
• Purpose (of the computing facility)
• E.g., “protect customers’ confidentiality”, “ensure continual
usability”
• Protected resources
• Purpose
• All computers? Networks? All data? Customers’ data? etc.
• A policy is written for several different groups
• Protection
• Beneficiaries
• What degree of protection to which resources
• Their needs should be captured in the policy
• Coverage
• Users
• Must be comprehensive enough; general enough to apply to new
cases
• Policy should indicate acceptable use
• Durability
• Owners
• Must grow and adapt well
• Policy should express the expectation of owners
• Realism
• Balance
• Protection requirements must be realizable with existing
mechanisms
• Needs of above groups may conflict
• Balance the priorities of all affected communities
104
• Usefulness
103
EXAMPLES
• Must be read, understood and followed by all
INFORMATION SECURITY POLICY,
STANDARDS AND PRACTICES
• Four levels S1 o S4 with increasing strength of protection
• S1: is not designed to protect any specific resources or any
specific level of protection to services
• S2: designed to protect regular resources and to provide normal
protection against threats
• S3: important resources, high protection
• Management from all communities of interest must
consider policies as the basis for all information security
efforts
• Policies direct how issues should be addressed and
technologies used
• Security policies are the least expensive control to
execute, but the most difficult to implement
• Shaping policy is difficult because:
• S4: critical resources, very strong protection
105
• Never conflict with laws
• Stand up in court, if challenged
• Be properly administered
106
TYPES OF POLICY
DEFINITIONS
• A policy is
Management defines three types of security policy:
A plan or course of action, as of a government, political party, or
business, intended to influence and determine decisions, actions,
and other matters
• General or security program policy
• Issue-specific security policies
• Systems-specific security policies
• Policies are organizational laws
• Standards, on the other hand, are more detailed statements of what
must be done to comply with policy
• Practices, procedures and guidelines effectively explain how to
comply with policy
• For a policy to be effective it must be properly disseminated, read,
understood and agreed to by all members of the organization
107
108
SECURITY PROGRAM POLICY
POLICIES STANDARDS &
PRACTICES
• A security program policy (SPP) is also known as a general
security policy, IT security policy, or information security
policy
• Sets the strategic direction, scope, and tone for all security
efforts within the organization
• An executive-level document, usually drafted by or with, the
CIO of the organization and is usually 2 to 10 pages long
110
109
ISSUE-SPECIFIC SECURITY
POLICY (ISSP)
• As various technologies and processes are
implemented, certain guidelines are needed to
use them properly
• The ISSP:
• addresses specific areas of technology
• requires frequent updates
• contains an issue statement on the organization’s
position on an issue
• Three approaches:
• Create a number of independent ISSP documents
• Create a single comprehensive ISSP document
• Create a modular ISSP document
EXAMPLE ISSP STRUCTURE
• Statement of Policy
• Authorized Access and Usage of Equipment
• Prohibited Usage of Equipment
• Systems Management
• Violations of Policy
• Policy Review and Modification
• Limitations of Liability
111
EXAMPLE POLICY
112
SYSTEMS-SPECIFIC POLICY
• While issue-specific policies are formalized as
written documents, distributed to users, and
agreed to in writing, SysSPs are frequently
codified as standards and procedures used when
configuring or maintaining systems
• Systems-specific policies fall into two groups:
• Access control lists (ACLs) consists of the access
control lists, matrices, and capability tables governing
the rights and privileges of a particular user to a
particular system
• Configuration
Rules
comprise
the
specific
configuration codes entered into security systems to
guide the execution of the system
113
114
INFORMATION SECURITY AUDIT
• Conduct of regular Information Security Audit will
improve Governance and management of your
system.
Systems Design
• Provide better understanding of information and the
system where the information resides.
• Improve Governance over all system data.
• The key word is UNDERSTANDING.
“Managing the unknown will lead to less than optimal
data quality.”
115
SYSTEMS DESIGN
116
THE SECSDLC
• At this point in the Security SDLC, the analysis phase is
complete and the design phase begins – many work
products have been created
• Designing a plan for security begins by creating or
validating a security blueprint
• Then use the blueprint to plan the tasks to be
accomplished and the order in which to proceed
• Setting priorities can follow the recommendations of
published sources, or from published standards provided
by government agencies, or private consultants
117
118
ISO 17799/BS 7799
INFORMATION SECURITY
BLUEPRINTS
• One approach is to adapt or adopt a published model or framework
for information security
• A framework is the basic skeletal structure within which additional
detailed planning of the blueprint can be placed as it is developed
of refined
• Experience teaches us that what works well for one organization
may not precisely fit another
• One of the most widely referenced and often discussed
security models is the Information Technology – Code of
Practice for Information Security Management, which was
originally published as British Standard 7799
• This Code of Practice was adopted as an international
standard by the International Organization for
Standardization
(ISO)
and
the
International
Electrotechnical Commission (IEC) as ISO/IEC 17799 in
2000 as a framework for information security
120
119
BS7799-2
ISO 17799 / BS 7799
• Several countries have not adopted 17799 claiming
there are fundamental problems:
• The global information security community has not
defined any justification for a code of practice as identified
in the ISO/IEC 17799
• 17799 lacks “the necessary measurement precision of a
technical standard”
• There is no reason to believe that 17799 is more useful than
any other approach currently available.
• 17799 is not as complete as other frameworks available
• 17799 is perceived to have been hurriedly prepared given
the tremendous impact its adoption could have on industry
information security controls
121
ISO/IEC 17799
NIST SECURITY MODELS
• Organizational Security Policy is needed to provide
management direction and support
• Objectives:
•
•
•
•
•
•
•
•
•
•
122
Operational Security Policy
Organizational Security Infrastructure
Asset Classification and Control
Personnel Security
Physical and Environmental Security
Communications and Operations Management
System Access Control
System Development and Maintenance
Business Continuity Planning
Compliance
• Another approach available is described in the
many documents available from the Computer
Security Resource Center of the National Institute for
Standards and Technology (csrc.nist.gov) –
Including:
• NIST SP 800-12 - The Computer Security Handbook
• NIST SP 800-14 - Generally Accepted Principles and
Practices for Securing IT Systems
• NIST SP 800-18 - The Guide for Developing Security Plans
for IT Systems
123
NIST SP 800-14
124
IETF SECURITY ARCHITECTURE
• Security Supports the Mission of the Organization
• Security is an Integral Element of Sound Mgmt
• Security Should Be Cost-Effective
• Systems Owners Have Security Responsibilities Outside Their
Own Organizations
• Security Responsibilities and Accountability Should Be Made
Explicit
• Security Requires a Comprehensive and Integrated Approach
• Security Should Be Periodically Reassessed
• While no specific architecture is promoted through
the Internet Engineering Task Force, the Security
Area Working Group acts as an advisory board for
the protocols and areas developed and promoted
through the Internet Society
• RFC 2196: Site Security Handbook provides an
overview of five basic areas of security with detailed
discussions on development and implementation
• There are chapters on such important topics as
security policies, security technical architecture,
security services, and security incident handling
• Security is Constrained by Societal Factors
125
• 33 Principles enumerated
126
BASELINING AND BEST
PRACTICES
VISA MODEL
• Visa International promotes strong security
measures and has security guidelines
• Developed two important documents that improve
and regulate its information systems
• “Security Assessment Process”
• “Agreed Upon Procedures”
• Using the two documents, a security team can
develop a sound strategy for the design of good
security architecture
• The only down side to this approach is the very
specific focus on systems that can or do integrate
with VISA’s systems
127
• Baselining and best practices are solid methods for
collecting security practices, but can have the
drawback of providing less detail than would a
complete methodology
• It is possible to gain information by baselining and
using best practices and thus work backwards to an
effective design
• The Federal Agency Security Practices Site
(fasp.csrc.nist.gov) is designed to provide best
practices for public agencies and adapted easily to
private organizations
128
PROFESSIONAL MEMBERSHIP
HYBRID FRAMEWORK
• It may be worth the information security professional’s
time and money to join professional societies with
information on best practices for its members
• The framework proposed here is the result of a detailed
analysis of the components of all the documents, standards,
and Web-based information described in the previous sections
• Many organizations have seminars and classes on best
practices for implementing security
• It is offered to the student as a balanced introductory blueprint
for learning the blueprint development process
• Finding information on security design is the easy part,
sorting through the collected mass of information,
documents, and publications can take a substantial
investment in time and human resources
129
130
NIST SP 800-26
NIST SP 800-26
Management Controls
•
•
•
•
•
Operational Controls
•
•
•
•
•
•
•
•
•
Risk Management
Review of Security Controls
Life Cycle Maintenance
Authorization of Processing (Certification and Accreditation)
System Security Plan
Personnel Security
Physical Security
Production, Input/Output Controls
Contingency Planning
Hardware and Systems Software
Data Integrity
Documentation
Security Awareness, Training, and Education
Incident Response Capability
Technical Controls
• Identification and Authentication
• Logical Access Controls
• Audit Trails
131
132
SPHERES OF SECURITY
SPHERE OF USE
• Generally speaking, the concept of the sphere is
to represent the 360 degrees of security
necessary to protect information at all times
• The first component is the “sphere of use”
• Information, at the core of the sphere, is
available for access by members of the
organization
and
other
computer-based
systems:
133
• To gain access to the computer systems, one must
either directly access the computer systems or go
through a network connection
• To gain access to the network, one must either
directly access the network or go through an Internet
134
connection
SPHERE OF PROTECTION
• The “sphere of protection” overlays each of the
levels of the “sphere of use” with a layer of security,
protecting that layer from direct or indirect use
through the next layer
• The people must become a layer of security, a
human firewall that protects the information from
unauthorized access and use
• Information security is therefore designed and
implemented in three layers
Controls
• policies
• people (education, training and awareness programs)
• technology
135
136
CONTROLS
• Management Controls cover security processes
that are designed by the strategic planners and
performed by security administration of the
organization
• Operational Controls deal with the operational
functionality of security in the organization
• Operational controls also address personnel
security, physical security and the protection of
production inputs and outputs
• Technical Controls address those tactical and
technical issues related to designing and
implementing security in the organization
137
Security and the Software Development Lifecycle
(SDLC)
Online Video follows: 32 minutes
138
Process of Auditing Information Systems
Online Video follows: 1 Hour 19 minutes
139
140
COMPONENTS OF AN INFORMATION
SYSTEM
• Information System (IS) is entire set of
software, hardware, data, people, procedures,
and networks necessary to use information as
a resource in the organization
141
142
SECURING COMPONENTS
• Computer can be subject of an attack and/or
the object of an attack
FIGURE 1-5 – SUBJECT AND
OBJECT OF ATTACK
• When the subject of an attack, computer is
used as an active tool to conduct attack
• When the object of an attack, computer is the
entity being attacked
143
144
FIGURE 1-6 – BALANCING
SECURITY AND ACCESS
BALANCING INFORMATION
SECURITY AND ACCESS
• Impossible to obtain perfect security—it is a
process, not an absolute
• Security should be considered
between protection and availability
balance
• To achieve balance, level of security must
allow reasonable access, yet protect against
threats
146
145
APPROACHES TO INFORMATION
SECURITY IMPLEMENTATION:
BOTTOM-UP APPROACH
• Grassroots effort: systems administrators attempt
to improve security of their systems
• Key advantage: technical expertise of individual
administrators
• Seldom works, as it lacks a number of critical
features:
• Participant support
148
• Organizational staying power
147
THE SYSTEMS DEVELOPMENT LIFE
CYCLE
APPROACHES TO INFORMATION
SECURITY IMPLEMENTATION: TOPDOWN APPROACH
• Initiated by upper management
• Systems development life cycle (SDLC) is methodology and
design for implementation of information security within an
organization
• Issue policy, procedures and processes
• Dictate goals and expected outcomes of project
• Determine accountability for each required
action
• The most successful also involve formal
development strategy referred to as systems
development life cycle
149
• Methodology is formal approach to problem-solving based
on structured sequence of procedures
• Using a methodology
• ensures a rigorous process
• avoids missing steps
• Goal is creating a comprehensive security posture/program
• Traditional SDLC consists of six general phases
150
INVESTIGATION
• What problem is the system being developed to
solve?
• Objectives, constraints and scope of project are
specified
• Preliminary cost-benefit analysis is developed
• At the end, feasibility analysis is performed to
assesses economic, technical, and behavioral
feasibilities of the process
151
ANALYSIS
152
LOGICAL DESIGN
• Consists of assessments of the organization, status
of current systems, and capability to support
proposed systems
• Analysts determine what new system is expected
to do and how it will interact with existing systems
• Ends with documentation of findings and update
of feasibility analysis
• Main factor is business need; applications
capable of providing needed services are
selected
• Data support and structures capable of
providing the needed inputs are identified
• Technologies to implement physical solution
are determined
• Feasibility analysis performed at the end
153
154
PHYSICAL DESIGN
IMPLEMENTATION
• Technologies to support the alternatives identified
and evaluated in the logical design are selected
• Needed
software
created; components
ordered, received, assembled, and tested
• Components evaluated on make-or-buy decision
• Users trained and documentation created
• Feasibility analysis performed; entire solution
presented to end-user representatives for
approval
155
• Feasibility analysis prepared; users presented
with system for performance review and
acceptance test
156
MAINTENANCE AND CHANGE
• Consists of tasks necessary to support and
modify system for remainder of its useful life
• Life cycle continues until the process begins
again from the investigation phase
• When current system can no longer support
the organization’s mission, a new project is
implemented
157
THE SECURITY SYSTEMS
DEVELOPMENT LIFE CYCLE
• The same phases used in traditional SDLC
may be adapted to support specialized
implementation of an IS project
• Identification of specific threats and creating
controls to counter them
• SecSDLC is a coherent program rather than a
series of random, seemingly unconnected
actions
158
INVESTIGATION
ANALYSIS
• Identifies process, outcomes, goals, and
constraints of the project
• Documents from investigation phase are studied
• Begins with enterprise information security
policy
• Analyzes existing security policies or programs,
along with documented current threats and
associated controls
• Organizational
performed
• Includes analysis of relevant legal issues that
could impact design of the security solution
feasibility
analysis
is
• The risk management task begins
159
LOGICAL DESIGN
• Creates and develops
information security
blueprints
160
PHYSICAL DESIGN
for
• Needed security technology is evaluated,
alternatives generated, and final design
selected
• Incident response actions planned:
• Continuity planning
• Incident response
• Disaster recovery
• Feasibility analysis to determine whether
project should continue or be outsourced
161
• At end of phase, feasibility study determines
readiness of organization for project
162
IMPLEMENTATION
MAINTENANCE AND CHANGE
tested,
• Perhaps the most important phase, given the everchanging threat environment
• Personnel issues evaluated; specific training
and education programs conducted
• Often, reparation and restoration of information is
a constant duel with an unseen adversary
• Entire tested package is presented
management for final approval
• Information security profile of an organization
requires constant adaptation as new threats
emerge and old threats evolve
• Security solutions are acquired,
implemented, and tested again
to
163
SECURITY PROFESSIONALS AND
THE ORGANIZATION
164
SENIOR MANAGEMENT
• Chief Information Officer (CIO)
• Wide range of professionals required to
support a diverse information security
program
• Senior management is key component; also,
additional
administrative
support
and
technical expertise required to implement
details of IS program
• Senior technology officer
• Primarily
responsible
for
advising
senior
executives on strategic planning
• Chief Information Security Officer (CISO)
• Primarily responsible for assessment, management,
and implementation of IS in the organization
• Usually reports directly to the CIO
166
165
INFORMATION SECURITY
PROJECT TEAM
DATA OWNERSHIP
• A number of individuals who are experienced
in one or more facets of technical and nontechnical areas:
• Champion
• Team leader
• Security policy developers
• Risk assessment specialists
• Data Custodian: responsible for storage,
maintenance, and protection of information
• Data Users: end users who work with
information to perform their daily jobs
supporting the mission of the organization
• Security professionals
• Systems administrators
• End users
• Data Owner: responsible for the security and
use of a particular set of information
168
167
COMMUNITIES OF INTEREST
• Group of individuals united by
interest/values in an organization
• Information
Security
Professionals
Management
• Information Technology
Professionals
KEY TERMS
similar
Management
and
and
• Organizational Management and Professionals
169
• Security Blueprint
• Access
• Asset
• Security Model
• Attack
• Security Posture or
• Control, Safeguard or
Security Profile
Countermeasure
•
Subject
• Exploit
• Exposure
• Threats
• Hacking
• Threat Agent
• Object
• Vulnerability
• Risk
170
SUMMARY
SUMMARY
• Information security is a “well-informed sense
of assurance that the information risks and
controls are in balance.”
• Computer security began immediately after
first mainframes were developed
• Successful organizations have multiple layers
of security in place: physical, personal,
operations, communications, network, and
information.
171
Any Questions?
173
• Security should be considered a balance between protection
and availability
• Information security must be managed similar to any major
system implemented in an organization using a methodology
like SecSDLC
172
Student Assessment Information
The process you will be following is known as competency-based assessment. This means that
evidence of your current skills and knowledge will be measured against national and international
standards of best practice, not against the learning you have undertaken either recently or in the
past. (How well can you do the job?)
Some of the assessment will be concerned with how you apply the skills and knowledge in your
workplace, and some in the training room.
The assessment tasks utilized in this training have been designed to enable you to demonstrate the
required skills and knowledge and produce the critical evidence required so you can successfully
demonstrate competency at the required standard.
What happens if your result is ‘Not Yet Competent’ for one or more assessment tasks?
The assessment process is designed to answer the question “has the participant satisfactorily
demonstrated competence yet?” If the answer is “Not yet”, then we work with you to see how we can
get there.
In the case that one or more of your assessments has been marked ‘NYC’, your Trainer will provide
you with the necessary feedback and guidance, in order for you to resubmit/redo your assessment
task(s).
What if you disagree on the assessment outcome?
You can appeal against a decision made in regards to an assessment of your competency. An appeal
should only be made if you have been assessed as ‘Not Yet Competent’ against specific competency
standards and you feel you have sufficient grounds to believe that you are entitled to be assessed as
competent.
You must be able to adequately demonstrate that you have the skills and experience to be able to
meet the requirements of the unit you are appealing against the assessment of.
You can request a form to make an appeal and submit it to your Trainer, the Course Coordinator, or
an Administration Officer. The RTO will examine the appeal and you will be advised of the outcome
within 14 days. Any additional information you wish to provide may be attached to the form.
What if I believe I am already competent before training?
If you believe you already have the knowledge and skills to be able to demonstrate competence in this
unit, speak with your Trainer, as you may be able to apply for Recognition of Prior Learning (RPL).
Credit Transfer
Credit transfer is recognition for study you have already completed. To receive Credit Transfer, you
must be enrolled in the relevant program. Credit Transfer can be granted if you provide the RTO with
certified copies of your qualifications, a Statement of Attainment or a Statement of Results along with
Credit Transfer Application Form. (For further information please visit Credit Transfer Policy)
243 | P a g e
LEARNING OUTCOMES
The following critical aspects must be assessed as part of this unit:
1. Interact with customers, collect the necessary information and match customers' needs to company
products or service
2. Sell products and services including matching customers' requirements to company products and
services and finalise and record the sale
LEARNING ACTIVITIES
Class will involve a range of lecture based training, activities, written task, case study and questioning.
STUDENT FEEDBACK
We welcome your feedback as one way to keep improving this unit. Later this semester, you will be
encouraged to give unit feedback through completing the Quality of Teaching and Learning Survey
LEARNING RESOURCES
Other Learning Resources available to students include:

Candidate Resource & Assessment: ICTNWK510 Develop, implement and evaluate system and
application security

Presentation handout

PPT Presentation
TEXTBOOKS
You do not have to purchase the following textbooks but you may like to refer to them:
Unit Code(s)
Unit Title
ICTNWK510
Develop, implement and
evaluate system and
application security
Reference Book/ Trainer & Learner Resource

7BCole, Kris. 2010 Management Theory
and Practice Network Security Essentials:
Applications and Standards, 4th Edition;
William Stallings
244 | P a g e
Additional Reference Texts

A Developers Guide to Network Security;
Richard Conway, Julian Cordingley

Firewalls and Network Security; Michael E.
Whitman, Herbert Mattford, Richard
Austin, Greg Holden

Network Security: The Complete Reference
1st Edition; Roberta Bragg, Keith
Strassberg, Mark Rhodes-Ousley

Network Security Bible 2nd Edition; Eric
Cole

Cryptography and Quantum Computing:
Securing Business Information; Bradley
Tice

7BCole, Kris. 2010 Management Theory
and Practice Network Security Essentials:
Applications and Standards, 4th Edition;
William Stallings

A Developers Guide to Network Security;
Richard Conway, Julian Cordingley

Firewalls and Network Security; Michael E.
Whitman, Herbert Mattford, Richard
Austin, Greg Holden

Network Security: The Complete Reference
1st Edition; Roberta Bragg, Keith
Strassberg, Mark Rhodes-Ousley

Network Security Bible 2nd Edition; Eric
Cole

Cryptography and Quantum Computing:
Securing Business Information; Bradley
Tice
ASSESSMENT DETAILS
Assessment Summary
The assessment for this unit consists of the following items.
Knowledge Assessment
245 | P a g e
Task 1: Systems Analysis and Design
Task 2: Develop, implement and evaluate system and application security
Formative Activities
In addition to the three assessment tasks, students will be required to complete activities as outlined
by their trainer/assessor – these will be taken from class resources, Enhance Your Future Learner
Guides.
Referencing Style
Students should use the referencing style outlined by the Trainer when preparing assignments. More
information can be sought from your Course Trainer.
Guidelines for Submission
1. An Assignment Cover Sheet (or cover page) must accompany all assignments at front to
confirm it is your own assessment/ work.
2. All assignments must be within the specified timeframe (please refer to Due Date).
Assignment Marking
Students should allow 14 days’ turnaround for written assignments.
Plagiarism Monitoring
Students should use the referencing style outlined by when preparing assignments. More information
can be sought from your Trainer.
Marking Guide
C
Competent: for students who have achieved all of the learning outcomes specified for
that unit/module to the specified standard.
NYC Not Yet Competent: for students who are required to re-enrol in a unit/ module in their
endeavour to achieve competence
S
Satisfactory: has achieved all the work requirements
246 | P a g e
NS
Not Satisfactory: has not achieved all the work requirements
Every student at Danford College can expect to have “timely fair and constructive assessment of
work.” Assessment tasks must be marked in such a way that the result reflects how well a student
achieved the learning outcomes and in accordance with the assessment criteria. In addition to the
final result, returned assignments must be accompanied by feedback that clearly explains how the
marking result/s was derived (summative), as well as how the student can improve (formative).
Refer to observation checklist below and/or consult your trainer/assessor for marking criteria for
this unit.
STUDENTS’ RIGHTS AND RESPONSIBILITIES
It is the responsibility of every student to be aware of all relevant legislation, policies and procedures
relating to their rights and responsibilities as a student. These include:

The Student Code of Conduct

The College’s policy and statements on plagiarism

Copyright principles and responsibilities

The College’s policies on appropriate use of software and computer facilities

Students’ responsibility to attend, update personal details and enrolment

Course Progress Policy and Attendance

Deadlines, appeals, and grievance resolution

Student feedback

Other policies and procedures.

Electronic communication with students
International Students Please also refer to ESOS framework for further details
https://internationaleducation.gov.au/Regulatory-Information/Education-Services-for-OverseasStudents-ESOS-Legislative-Framework/ESOS-Act
ADDITIONAL INFORMATION
Contacts:
If you have a query relating to administrative matters such as obtaining assessment results, please
contact your Course co-ordinator.
247 | P a g e
Deferrals/Suspensions/Cancellations
Danford College will only allow deferrals/student requested suspensions under exceptional
compassionate circumstances. Once a student has commenced studies, students are not allowed to
take leave unless there are compelling and compassionate reasons. Please refer to the College’s
Deferment, Suspension and Cancellation Policy available in the Student Handbook and at Student
Administration. This policy has been explained to you at Orientation.
Course Progress Policy
You are expected to attend all classes and complete your units of study satisfactorily, within your term.
Your Course Trainer will make a report to the Course co-ordinator if there are any concerns about your
progress. The Course Progress Policy is available to you in the Student Handbook and at Student
Administration or on college website www.danford.edu.au.
Assessment Conditions
Gather evidence to demonstrate consistent performance in conditions that are safe and replicate the
workplace. Noise levels, production flow, interruptions and time variances must be typical of those
experienced in the network industry, and include access to:

ICT business specifications

information on the security environment, including laws and legislation, existing
organisational security policies, organisational expertise and knowledge

possible security environment, which also includes the threats to security that are, or are held
to be, present in the environment

risk analysis tools and methodologies

ICT security assurance specifications

application and system scenarios.
Assessors must satisfy SRTO2015/AQF assessor requirements.
248 | P a g e
Lesson/Session Plan
For face-to-face classroom based delivery as per timetable.
Delivery Day
1
2
Delivery Topics
Introduction to ICTNWK510 Develop,
implement and evaluate system and
application security and Assessment
Requirements Overview (Page 5)
Identify enterprise ICT system or
application security policies (Page 10)
Identify security requirements for the
ICT system or application (Page 38)
Write an ICT system or application
security plan according to the
enterprise and ICT system or
application security policies (Page 58)
Identify standards against which to
engineer the ICT system or
application (Page 95)
AS/NZS ISO/IEC 38500:2010 ISO/IEC
38500:2008 Australian/New Zealand
Standard™ Corporate governance of
information technology
3
Identify criteria for performing risk
based audits against the ICT system
or application (Page 102)
Develop processes and procedures to
mitigate the introduction of
vulnerabilities during the engineering
process (Page 129)
4
Integrate applicable information
security requirements, controls,
processes, and procedures into ICT
system and application design
specifications according to
established requirements (Page 158)
Execute enterprise and ICT system or
application security policies (Page
169)
Apply and verify compliance with
identified standards against which to
engineer the ICT system or
application (Page 177)
Activities to be undertaken
Work through corresponding sections
of Learner Materials and Assessment
Tasks
Activity 1 (Page 17)
Activity 2 (Page 49)
Commence Written Questions
PowerPoint Presentation – Slides 1 68
Work through corresponding sections
of Learner Materials and Assessment
Tasks
Activity 3 (Page 90)
Activity 4 (Page 102)
Commence Task 1 – Systems Analysis
and Design
Commence Task 2 – Develop,
implement and evaluate system and
application security
PowerPoint Presentation – Slides 69 104
Work through corresponding sections
of Learner Materials and Assessment
Tasks
Activity 5 (Page 115)
Activity 6 (Page 146)
Work through corresponding sections
of Learner Materials and Assessment
Tasks
Activity 7 (Page 174)
Activity 8 (Page 181)
PowerPoint Presentation – Slides
105-113
249 | P a g e
Delivery Day
5
6
7
8
9
Delivery Topics
Perform processes and procedures to
mitigate the introduction of
vulnerabilities during the engineering
process (Page 184)
Perform secure configuration
management practices (Page 188)
Validate that the engineered ICT
system and application security
controls meet the specified
requirements (Page 202)
Re-engineer security controls to
mitigate vulnerabilities identified
during the operations phase (Page
204)
Ensure integration of information
security practices throughout the
SDLC process (Page 204)
Document ICT system or application
security controls addressed within
the system (Page 205)
Practise secure coding (Page 206)
Review new and existing risk
management technologies to achieve
an optimal enterprise risk posture
(Page 213)
Review new and existing ICT security
technologies to support secure
engineering across the SDLC phases
(Page 214)
Continually assess effectiveness of
the information system controls
based on risk management practices
and procedures (Page 215)
Assess and evaluate system
compliance with corporate policies
and architectures (Page 225)
Assess system maturation and
readiness for promotion to the
production stage (Page 228)
Collect lessons learned from
integration of information security
into the SDLC and use to identify
improvement actions (Page 231)
Collect, analyse and report
performance measures (Page 240)
Activities to be undertaken
Work through corresponding sections
of Learner Materials and Assessment
Tasks
Activity 9 (Page 198)
PowerPoint Presentation – Slides 114
- 132
Work through corresponding sections
of Learner Materials and Assessment
Tasks
PowerPoint Presentation – Slides 133
- 134
Work through corresponding sections
of Learner Materials and Assessment
Tasks
Activity 10 (Page 210)
PowerPoint Presentation – Slides 135
- 136
Work through corresponding sections
of Learner Materials and Assessment
Tasks
PowerPoint Presentation – Slides 137
- 171
Work through corresponding sections
of Learner Materials and Assessment
Tasks
Activity 11 (Page 238)
Activity 12 (Page 241)
Complete Written Questions
250 | P a g e
Delivery Day
10
Delivery Topics
ASSESSMENT
Activities to be undertaken
Complete Task 1 – Systems Analysis
and Design
Complete Task 2 – Develop,
implement and evaluate system and
application security
251 | P a g e
Knowledge Assessment (Written Tasks)
1. What is an Enterprise Security Policy?
2. What is an Information Systems Audit?
252 | P a g e
3. How is an Information Systems Audit Conducted?
4. Don’s company is using the waterfall model of software development. Which one of the
following transitions is not acceptable under this model?
253 | P a g e
(a) Code & Debug -> Testing
(b) System Requirements -> Software Requirements
(c) Testing -> Operations & Maintenance
(d) Software Requirements -> Testing
5. What are the Testing Levels?
(a) Unit Testing
(b) Integration Testing
(c) System Testing and Acceptance Testing.
(d) All the above
6. Requirement and Analysis, Design, Development or Coding, Testing and Maintenance is called
as Software Development Life Cycle (SDLC )
(a) True
(b) False
7. Configuration Management Plan describes the Configuration Management procedures and
structures to be used.
(a) True
(b) False
8. A metric used to measure the characteristic of documentation and code called as
(a) Process metric
(b) Product Metric
(c) Test metrics
9. Integration of security processes with the SDLC – Complete the table below to outline the
security processes related to the SDLC Phases:
SDLC Phases
Requirements
Security Processes
Design
Coding and Unit
Testing
Integration Testing
System Testing
254 | P a g e
Implementation
Support
10. A security evaluation report and an accreditation statement are produced in which of the
following phases of the system development life cycle?
255 | P a g e
Task 1 – Systems Analysis and Design
Answer All Questions:
True/False
Indicate whether the statement is true or false.
____ 1.
Systems analysis and design focuses on understanding the business problem and
outlining the approach to solve it.
____ 2.
When choosing between possible solutions to a business problem, the best solution
is the one with the fewest risks and the most benefits.
____
3.
A systems analyst needs to understand people and the way they work.
____
4.
A systems analyst needs to be an expert in all types of technology.
____
5.
Analysts must upgrade their knowledge and skills continually.
____
6.
Technology alone increases productivity and profits.
____ 7.
Systems analysis means understanding and specifying in detail what the information
system should accomplish.
____
8.
The systems analyst's work is described as problem solving for an organization.
____ 9.
A system is a collection of interrelated components that function together to
achieve some outcome.
____ 10.
The first four major phases of the predictive systems development life cycle (SDLC)
are the planning phase, the analysis phase, the design phase, and the prototyping phase.
____ 11.
The primary objective of analysis activities is to understand the business needs and
processing requirements of the new system.
____
12.
The support phase includes maintaining and enhancing the system.
____
13.
The first activity in the project planning phase is to develop the project schedule.
____ 14.
Feasibility analysis investigates economic, organizational, technical, resource, and
schedule feasibility.
____ 15.
The support phase is the shortest and least expensive phase of the system
development life cycle (SDLC).
____ 16.
A tool is a software support that helps create models or other components required
in the project.
256 | P a g e
____
17.
During the design phase, analysts begin to define a computer-system solution.
____ 18.
Implementation is the actual construction, testing, and installation of a functioning
information system.
____ 19.
The most important activity of project planning is to define precisely the business
problem and the scope of the required solution.
____
20.
A predictive SDLC has a high technical risk.
____
21.
A project cannot have both predictive and adaptive elements.
____ 22.
The spiral model is generally considered to be the first adaptive approach to system
development.
____ 23.
A methodology contains guidelines to follow for completing every activity in the
systems development life cycle.
____
24.
A project management software application is an example of a tool.
____
25.
Structured programming and top-down programming are identical concepts.
____ 26.
technique.
The data flow diagram is used with the structured analysis system development
____ 27.
approach.
The class diagram is used with the Information Engineering system development
____
A model is a representation of an important aspect of the real world.
28.
Multiple Choice
Identify the choice that best completes the statement or answers the question.
____ 29.
The process of understanding and specifying in detail what the information system
should accomplish is called systems ____.
a. design
c. analysis
b. specification
d. administration
____ 30.
Systems ____ means specifying in detail how the many components of the
information system should be physically implemented.
a. design
c. analysis
b. specification
d. administration
____
31.
The most important role of a systems analyst in business is ____.
257 | P a g e
a.
b.
c.
d.
technical understanding of information systems
problem solving
knowing what data needs to be stored and used
special programming skills
____ 32.
____ refers to the division of a system into processes or subsystems.
a. System design
c. Programming
b. Data management
d. Functional decomposition
____ 33.
An automation boundary is best described as the separation between the ____.
a. system and its environment
b. automated part of a system and the manual part of a system
c. manual part of a system and its environment
d. automated part of a system and its environment
____ 34.
Changes in software development, technology, and business practices have created
many new career opportunities for analysts, including ____.
a. Sales and support of ERP software
c. Web development
b. Auditing, compliance, and security
d. All of the above
____ 35.
A technique that seeks to alter the nature of the work done in a business function,
with the objective of radically improving performance, is called ____.
a. business process reengineering
c. information systems strategic planning
b. strategic planning
d. enterprise resource planning (ERP)
____ 36.
A description of the integrated information systems needed by the organization to
carry out its business functions is called ____.
a. business process re-engineering
c. technology architecture plan
b. application architecture plan
d. enterprise resource planning (ERP)
____ 37.
A description of the hardware, software, and communications networks required to
implement planned information systems is called ____.
a. information systems strategic planning
c. technology architecture plan
b. applications architecture planning
d. enterprise resource planning (ERP)
____ 38.
Rocky Mountain Outfitters would like to further distribute business applications
across multiple locations and computer systems, reserving the data center for Web server, database,
and telecommunications functions. This is an example of ____.
a. applications architecture planning
c. technology architecture planning
b. enterprise resource planning (ERP)
d. strategic planning
258 | P a g e
____ 39.
Which of the following is an example of a technique used to complete specific
system development activities?
a. project planning
b. integrated development environment (IDE)
c. application service provider (ASP)
d. supply chain management (SCM)
____ 40.
Which of the following is the analyst’s approach to problem solving?
a. Verify that the benefits of solving the problem outweigh the costs, then research and
understand the problem.
b. Develop a set of possible solutions, then verify that the benefits of solving the problem
outweigh the costs.
c. Verify that the benefits of solving the problem outweigh the costs, then define the
requirements for solving the problem.
d. Implement the solution, then define the details of the chosen solution.
____ 41.
The last step of the analyst's approach to problem solving is ____.
a. Decide which solution is best, and make a recommendation
b. Monitor to make sure that you obtain the desired results
c. Verify that the benefits of solving the problem outweigh the costs
d. Implement the solution
____ 42.
A knowledge management system ____.
a. indexes all the knowledge contained within an organization
b. supports the storage of and access to documents within an organization
c. is another term for a library system
d. requires a very large amount of online storage space
____ 43.
Skills in a nontechnical area such as interviewing and team management are called
____.
a. inherent skills
c. hard skills
b. technical skills
d. soft skills
____ 44.
An example of a project phase in a predictive project is ____.
a. gathering information about the user's needs
b. performing a project cost/benefit analysis
c. planning the project
d. drawing the system interface
259 | P a g e
____ 45.
The primary objective of the analysis phase is to ____.
a. analyze the capabilities and structure of the previous system
b. prioritize the alternatives for a new system
c. determine the basic structure and approach for the new system
d. understand and document the users' needs and requirements
____ 46.
The problem domain is the part of systems development that refers to the ____.
a. problems associated with the computing environment
b. area of the user's business for which a system is being developed
c. problems of the organization of the company
d. area of the industry that results in more intense competition
____ 47.
That portion of the new information system that satisfies the user's business needs
in the problem domain is referred to as the ____.
a. system procedure
c. network
b. application
d. user interface
____ 48.
The ____ phase begins only after the new system has been installed and put into
production, and it lasts throughout the productive life of the system.
a. analysis
c. implementation
b. design
d. support
____ 49.
Users are typically more involved in the project during which two phases?
a. Analysis and design
c. Design and implementation
b. Planning and analysis
d. Analysis and implementation
____ 50.
The first official activity of the project team as it initiates the project planning phase
is to ____.
a. define the business problem
c. develop a cost/benefit analysis
b. staff the project team
d. write a project proposal
____ 51.
The term “____” describes a planned undertaking that produces a new information
system.
a. systems development project
c. systems development life cycle (SDLC)
b. phase
d. design phase
____ 52.
Most new information systems must communicate with other, existing systems, so
the design of the method and details of these communication links must be precisely defined. These
are called ____.
a. models
c. help desks
260 | P a g e
b. system interfaces
d. design interfaces
____ 53.
The term “____” means that work activities are done once, then again, and yet
again.
a. eXtreme programming (XP)
c. agile modeling
b. iteration
d. Unified Process (UP)
____ 54.
The term ____ refers to an approach that completes parts of a system in one or
more iterations and puts them into operation for users.
a. incremental development
c. Unified Process (UP)
b. information engineering (IE)
d. structured design
____ 55.
A(n) ____ in system development is a collection of guidelines that help an analyst
complete a system development activity or task.
a. iteration
c. technique
b. model
d. tool
____
is one that has one beginning and one ending.
a. iterative
c. incremental
b. structured
d. object-oriented
56.
A(n) ____ program
____ 57.
____ programming divides more complex programs into a hierarchy of program
modules.
a. Incremental
c. Object-oriented
b. Iterative
d. Top-down
____ 58.
The key graphical model of the systems requirements used with structured analysis
is the ____.
a. flowchart
b. data flow diagram (DFD)
c. class diagram
d. project evaluation and review technique (PERT) chart
____ 59.
A(n) ____ is a thing in the computer system that is capable of responding to
messages.
a. entity-relationship diagram (ERD)
c. tool
b. model
d. object
261 | P a g e
____ 60.
The ____ is a critical component of any new system.
a. project management application
c. reverse engineering tool
b. user interface
d. code generator tool
____ 61.
The objective of the ____ phase is to keep the system running productively during
the years following its initial installation.
a. support
c. planning
b. design
d. analysis
____ 62.
The ____ technique was developed to provide some guidelines for deciding what the
set of programs should be, what each program should accomplish, and how the program should be
organized into a hierarchy.
a. Extreme programming (XP)
c. object-oriented
b. structured design
d. structure chart
____ 63.
A key concept in the ____ model approach is the focus on risk.
a. spiral
c. risk
b. Extreme programming (XP)
d. agile
____ 64.
A(n) _____ approach to the SDLC is used when the exact requirements of a system
or needs of users are not well understood.
a. predictive
c. incremental
b. persistent
d. adaptive
____ 65.
The _____ approach is an SDLC approach that assumes the various phases of a
project can be completed entirely sequentially.
a. waterfall
c. prototype
b. artifact
d. spiral model
____ 66.
Visual modelling tools usually contain a database of information about the models
and the project, which is called a(n) ____.
a. knowledge base
c. library
b. information base
d. repository
____ 67.
One popular visual modelling tool is ____.
a. Firefox
c. Visio
b. PowerPoint
d. Photoshop
262 | P a g e
Task 2 – Develop, implement and evaluate system and application security
This assessment task requires the development of a configuration script for a Cisco networking
device to meet the requirements of the network specification within the networking environment.
Your task is to handle system and application security from the development phase through
implementation to evaluation. Relevant standards to scripting in IOS must be applied to all coded
and applied scripts and security best practice must be applied.
During the development and implementation, vulnerabilities must be mitigated including:







buffer overflows
errors in application or system
poor design
trapdoors
undefined or undocumented code
undefined variables
untested code.
You should access and take into account:






IT business specifications
information on the security environment, including laws and legislation, existing
organisational security policies, organisational expertise and knowledge
possible security environment, which also includes the threats to security that are, or are
held to be, present in the environment
risk analysis tools and methodologies
IT security assurance specifications
application and system scenarios
Complete and submit the following:



Project overview
Copy of the applied and reviewed security policies
Checklist of Security-related Tasks & Subtasks
263 | P a g e
Checklist of Security-related Tasks & Subtasks
264 | P a g e
265 | P a g e
266 | P a g e
267 | P a g e
268 | P a g e
269 | P a g e
270 | P a g e
271 | P a g e
ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING
College Copy
Unit Code and Title: ICTNWK510 Develop, implement and evaluate system and
application security
Assessment task Due Dates
Assessment 1 Due Date:
Assessment 2 Due Date:
Assessment 3 Due Date:
I
Student ID
acknowledge receiving the
Student Assessment Information Pack, which contains:
o
o
o
o
o
o
o
o
Assessment Due Date Sheet
Time table /Training Plan
Lesson Plan
Student Assessment Information Guide
Assessment Cover Sheets
Feedback form
Student Resource
Internet Access for online Business Environment Simulation with Login Key or access to college
simulated business documents on internal intranet.
Student Signature:
Date
:
272 | P a g e
ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING
Student Copy
Unit Code and Title: ICTNWK510 Develop, implement and evaluate system and
application security
Assessment task Due Dates
Assessment 1 Due Date:
Assessment 2 Due Date:
Assessment 3 Due Date:
I
Student ID
acknowledge receiving the
Student Assessment Information Pack, which contains:
o
o
o
o
o
o
o
o
Assessment Due Date Sheet
Time table / Training Plan
Lesson Plan
Student Assessment Information Guide
Assessment Cover Sheets
Feedback form
Student Resource
Internet Access for online Business Environment Simulation with Login Key or access to college
simulated business documents on internal intranet.
Student Signature:
Date
:
273 | P a g e
ASSESSMENT SUMMARY / COVER SHEET
This form is to be completed by the assessor and used a final record of student competency.
All student submissions including any associated checklists (outlined below) are to be attached to
this cover sheet before placing on the students file. Student results are not to be entered onto the Student
Database unless all relevant paperwork is completed and attached to this form.
Student Name:
Student ID No:
Final Completion Date:
Unit Code:
ICTNWK510
Unit Title:
Develop, implement and evaluate system and application security
Assessors Name:
Unit
Outcome
C
NYC
Result: S = Satisfactory, NYS = Not Yet Satisfactory, NA = Not Assessed

Knowledge Assessment - Questions and Answers

Task 1
S | NYS | NA

Task 2
S | NYS | NA
S | NYS | NA
Is the Learner ready for assessment?
Yes
No
Has the assessment process been explained?
Yes
No
Yes
No
Yes
No
Yes
No
Does the Learner understand which evidence is to be collected and
how?
Have the Learner’s rights and the appeal system been fully
explained?
Have you discussed any special needs to be considered during
assessment?
I agree to undertake assessment in the knowledge that information gathered will only be used for
professional development purposes and can only be accessed by my manager and the RTO:
Learner Signature:
I have received, discussed and accepted my result as mentioned above for
this unit assessment and I am aware about my rights to appeal.
Date:
Assessor Signature:
I declare that I have conducted a fair, valid, reliable and flexible
assessment with this student, and I have provided appropriate feedback.
Date:
274 | P a g e
ASSESSMENT COVER SHEET
Unit
ICTNWK510 Develop, implement and evaluate system and application
security
Course
ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING
Student Name:
Student ID:
Group:
Date
Title of
Assignment:
Knowledge Assessment - Questions and Answers
Assessor Name:
This cover sheet must be attached to your assignment.
Declaration:
1. I am aware that penalties exist for plagiarism and unauthorized collusion with other
students.
2. I am aware of the requirements set by my educator with regards to the presentation
of documents and assignments.
3. I have retained a copy of my assignment.
Student Signature:___________________________
Date:________________________________________
275 | P a g e
QUESTION & ANSWER CHECKLIST
S
NYS
Learner’s name:
Assessor’s name:
Question
Correct ()
1
2
3
4
5
6
7
8
9
10
Feedback to Learner:
Assessor’s Signature:
Date:
276 | P a g e
ASSESSMENT COVER SHEET
Unit
ICTNWK510 Develop, implement and evaluate system and application
security
Course
ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING
Student Name:
Student ID:
Group:
Date
Title of
Assignment:
Task 1
Assessor Name:
This cover sheet must be attached to your assignment.
Declaration:
1. I am aware that penalties exist for plagiarism and unauthorized collusion with other
students.
2. I am aware of the requirements set by my educator with regards to the presentation
of documents and assignments.
3. I have retained a copy of my assignment.
Student Signature:___________________________
Date:________________________________________
277 | P a g e
TASK 1 CHECKLIST
S
NYS
Learner’s name:
Assessor’s name:
Observation Criteria
S
NS
Identified enterprise ICT system or application security policies
Identified security requirements for the ICT system or application
Wrote an ICT system or application security plan according to the
enterprise and ICT system or application security policies
Identified standards against which to engineer the ICT system or
application
Identified criteria for performing risk based audits against the ICT system
or application
Developed processes and procedures to mitigate the introduction of
vulnerabilities during the engineering process
Integrated applicable information security requirements, controls,
processes, and procedures into ICT system and application design
specifications according to established requirements
Executed enterprise and ICT system or application security policies
Applied and verified compliance with identified standards against which
to engineer the ICT system or application
Performed processes and procedures to mitigate the introduction of
vulnerabilities during the engineering process
Performed secure configuration management practices
Validated that the engineered ICT system and application security
controls meet the specified requirements
Re-engineered security controls to mitigate vulnerabilities identified
during the operations phase
Ensured integration of information security practices throughout the
SDLC process
Documented ICT system or application security controls addressed
within the system
Practised secure coding
Reviewed new and existing risk management technologies to achieve an
optimal enterprise risk posture
Reviewed new and existing ICT security technologies to support secure
engineering across the SDLC phases
278 | P a g e
Continually assessed effectiveness of the information system controls
based on risk management practices and procedures
Assessed and evaluated system compliance with corporate policies and
architectures
Assessed system maturation and readiness for promotion to the
production stage
Collected lessons learned from integration of information security into
the SDLC and use to identify improvement actions
Collected, analyse and report performance measures
Feedback to Learner:
Assessor’s Signature:
Date:
279 | P a g e
ASSESSMENT COVER SHEET
Unit
ICTNWK510 Develop, implement and evaluate system and application
security
Course
ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING
Student Name:
Student ID:
Group:
Date
Title of
Assignment:
Task 2
Assessor Name:
This cover sheet must be attached to your assignment.
Declaration:
1. I am aware that penalties exist for plagiarism and unauthorized collusion with other
students.
2. I am aware of the requirements set by my educator with regards to the presentation
of documents and assignments.
3. I have retained a copy of my assignment.
Student Signature:___________________________
Date:________________________________________
280 | P a g e
TASK 2 CHECKLIST
S
NYS
Learner’s name:
Assessor’s name:
Observation Criteria
S
NS
Identified enterprise ICT system or application security policies
Identified security requirements for the ICT system or application
Wrote an ICT system or application security plan according to the
enterprise and ICT system or application security policies
Identified standards against which to engineer the ICT system or
application
Identified criteria for performing risk based audits against the ICT system
or application
Developed processes and procedures to mitigate the introduction of
vulnerabilities during the engineering process
Integrated applicable information security requirements, controls,
processes, and procedures into ICT system and application design
specifications according to established requirements
Executed enterprise and ICT system or application security policies
Applied and verified compliance with identified standards against which
to engineer the ICT system or application
Performed processes and procedures to mitigate the introduction of
vulnerabilities during the engineering process
Performed secure configuration management practices
Validated that the engineered ICT system and application security
controls meet the specified requirements
Re-engineered security controls to mitigate vulnerabilities identified
during the operations phase
Ensured integration of information security practices throughout the
SDLC process
Documented ICT system or application security controls addressed
within the system
Practised secure coding
Reviewed new and existing risk management technologies to achieve an
optimal enterprise risk posture
Reviewed new and existing ICT security technologies to support secure
engineering across the SDLC phases
281 | P a g e
Continually assessed effectiveness of the information system controls
based on risk management practices and procedures
Assessed and evaluated system compliance with corporate policies and
architectures
Assessed system maturation and readiness for promotion to the
production stage
Collected lessons learned from integration of information security into
the SDLC and use to identify improvement actions
Collected, analyse and report performance measures
Feedback to Learner:
Assessor’s Signature:
Date:
282 | P a g e
Student Feedback Form
Unit
ICTNWK510 Develop, implement and evaluate system and
application security
Student Name:
Date
Assessor Name:
Please provide us some feedback on your assessment process. Information provided on this form
is used for evaluation of our assessment systems and processes.
This information is confidential and is not released to any external parties without your written
consent. There is no need to sign your name as your feedback is confidential.
Strongly
Strongly
Agree
Disagree
Agree
I received information about the assessment
requirements prior to undertaking the tasks
1
2
3
4
5
The assessment instructions were clear and easy to
understand
1
2
3
4
5
I understood the purpose of the assessment
1
2
3
4
5
The assessment meet your expectation
1
2
3
4
5
My Assessor was organised and well prepared
1
2
3
4
5
The assessment was Fair, Valid, Flexible and Reliable
1
2
3
4
5
My Assessor's conduct was professional
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
The assessment was an accurate reflection of the
unit requirements
I was comfortable with the outcome of the
assessment
I received feedback about assessments I completed
The pace of this unit was:
Too Slow
Great
Pace
Too Fast
Comments:
283 | P a g e