0% found this document useful (0 votes)
125 views

Information Security Program

The document discusses an information security program, including its objectives, elements, and resources. An information security program aims to identify, communicate, and address risks through controls, processes, and practices. It should be supported by senior management, aligned with organizational objectives, and assessed through metrics.

Uploaded by

Balan Wv
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
125 views

Information Security Program

The document discusses an information security program, including its objectives, elements, and resources. An information security program aims to identify, communicate, and address risks through controls, processes, and practices. It should be supported by senior management, aligned with organizational objectives, and assessed through metrics.

Uploaded by

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

Domain 3 - Information Security Program

Information Security Program Overview

Information Security Programs - the collection of activities used to identify,


communicate, and address risks.

The security program consists of controls, processes, and practices to increase the
resilience of the computing environment and ensure that risks are known and handled
in an effective manner.

Because every organization is different, security managers need to understand their


organizations’ internal workings so that their security programs can effectively
align with the organization’s operations, practices, and culture.

The activities in an information security program serve to operationalize the


security manager’s vision for effective security and risk management in the
organization, which is focused on how the security program aligns and supports the
business.

Outcomes - should be the realization of the strategy, goals, and objectives of the
organization.

Three elements essential to successful Information Security Programs (ISP):

1. Well designed & supported by senior management


2. Well executed & aligned with organizational objectives
3. Well measured and assessed through metrics

REMEMBER FROM DOMAIN 1 -->

DEFINITION OF OVERALL SECURITY OBJECTIVES + RISK ASSESSMENT = SECURITY


STRATEGY

*** It is the Information Security Manager that defines the objectives

The ISP is the process that allows an organization to design, build, deploy,
modify, manage, monitor & maintain security systems until they are retired.

Program Charter - a formal, written definition of the objectives of a program, its


main timelines, the sources of funding, the names of its principal leaders and
managers, and the business executives who are sponsoring the program.

NOTE: also demonstrates support from the executive leadership team

An information security program charter gives authority to the security manager to


perform several functions, including the following:
• Develop and enforce security policy

• Develop and implement the risk management process

• Develop and manage security governance

• Develop and direct the implementation and operation of controls across


department or business unit boundaries

• Develop and direct the implementation of key security processes, including


vulnerability management, incident management, third-party risk, security
architecture, business continuity planning, and security awareness training

Keep in mind that a charter empowers the security manager to be a facilitator of


security in the organization, not the dictator of security.

The security charter gives the security manager authority to design and operate the
program, but accountability is shared between the security manager and the
executive leadership team and board of directors.

Scope of a program - defines the boundaries and what parts of the organization are
to be included and subject to information security governance and policy.

Road Map - the steps required to achieve a strategy or strategic objective in


support of the business vision and mission.

In the context of developing or making key improvements to an information security


program, a road map will consist of various tasks and projects that will result in
the creation and implementation of capabilities that contribute to a reduction of
information risk.

Enterprise architecture (EA) - both a business function and a model

a. business function - consists of activities that ensure that important


business needs are met by IT systems.

b. model - used to map business functions into the IT environment and IT


systems in increasing levels of detail so that IT professionals can understand the
organization’s technology architecture at any level.

Information security architecture - a subset within enterprise architecture that is


concerned with two things:

a. protective characteristics found in many components in an overall


enterprise architecture

b. specific components in an enterprise architecture that provide preventive


or detective security functions

The purpose of enterprise architecture and information security architecture


ensures the following:

• All hardware and software components fulfill a stated specific business


purpose

• There is overall structure and consistency in infrastructure throughout the


organization

• Infrastructure resources are used efficiently

• Infrastructure is scalable and flexible

Information security architecture exists in two main layers in an organization:

• Policy
• Standards

There are six objectives that ALL Information Security Programs should achieve:

1. Strategic alignment
2. Risk management
3. Value delivery
4. Resource management
5. Performance measurement
6. Assurance process integration

===================

Information Security Program Resources

The objective of the Information Security Program (ISP) is to implement strategy in


a cost effective manner, while maximizing support for business functions &
minimizing operational disruptions

Defining objectives = identifying forces driving business need(s) --> GAP ANALYSIS
IS IMPORTANT HERE...

The Information Security Manager is responsible for establishment of the ISP scope

The steps involved in developing an ISP are:

1. Determine desired outcomes for security


2. Define current & desired states
3. Perform Gap Analysis between current & desired states
4. Develop strategy to close gap(s) identified
5. Create roadmap to navigate strategy
6. Develop program to implement strategy
7. Manage program to meet objectives
*** Risk management activities should be used to assess current risk,
strategy, program development & management across steps 2 through 7

Remember the impacts of challenges & constraints as you develop the ISP

What do we really need to have a handle on --> Resources & Constraints

Resources - things that allow us to accomplish our objectives

_
|T| echnology
|A| rchitecture
|P| eople
|P| rocess
_

Constraints - things that attempt to prevent us from accomplishing our objectives

Good | Fast | Cheap

Resources | Time | $$$

*** Do not forget about regulatory/statutory constraints !!!

===================

Information Asset Identification & Classification

In order to deliver cost-effective security through an ISP, we must establish and


undertsand the valuation of ALL assets to be protected

Approaches include:

1. Loss scenarios (quantitative)


2. Qualitative analysis
3. Hybrid (quantitaive + qualitative)
4. Purchase price
5. Value Add

Classification vs Categorization -

The purpose of a classification system is to ensure information/assets are marked


in such a way that only those with an appropriate level of clearance can have
access to them.

Categorization is the process of determining the impact of the loss of


confidentiality, integrity, or availability of the information/asset to an
organization.
SP 800-60 Vol. 1 Rev. 1 - Guide for Mapping Types of Information and Information
Systems to Security Categories

Who should decide on data classification? The individual who owns the data should
decide on the classification, and it should be reviewed at a minimum annually.

Method to determine criticality of assets:

1. Break corporate structure down into business units & rate each unit based
on value to the business (REVENUE); done by senior management

2. Identify critical organizational functions by business unit, ranking their


priority by unit

3. Assets that enable/support each critical function are identified and


priority ranked

4. Risk(s) are then identified and associated with assets

===================

Standards & Frameworks for Information Security

Sherwood Applied Business Security Architecture (SABSA) -

A methodology for developing business-driven, risk and opportunity focused Security


Architectures at both enterprise and solutions level that traceably support
business objectives.

It is also widely used for Information Assurance Architectures, Risk Management


Frameworks, and to align and seamlessly integrate security and risk management into
IT Architecture methods and frameworks.

SABSA is comprised of a series of integrated frameworks, models, methods and


processes, used independently or as an holistic integrated enterprise solution,
including:

Business Requirements Engineering Framework (known as Attributes Profiling)


Risk and Opportunity Management Framework
Policy Architecture Framework
Security Services-Oriented Architecture Framework
Governance Framework
Security Domain Framework
Through-life Security Service Management & Performance Management Framework

=======================================================
| Business View | Contextual Architecture |
|======================|================================|
| Architect's View | Conceptual Architecture |
|======================|================================|
| Designer's View | Logical Architecture |
|======================|================================|
| Constructor's View | Physical Architecture |
|======================|================================|
| Technician's View | Component Architecture |
|======================|================================|
| Manager's View | Management Architecture |
|======================|================================|

Strategy & Planning --> Design --> Implement --> Manage & Measure

The OPEN Group Architecture Framework (TOGAF) Standard, Version 9.2/10.0

In particular, the following concepts are included:

Partitioning – a number of techniques and considerations on how to partition


the various architectures within an enterprise.

Architecture Repository – a logical information model for an Architecture


Repository which can be used as an integrated store for all outputs created by
executing the Architecture Development Method (ADM).

Capability Framework – a structured definition of the organization, skills,


roles, and responsibilities required to operate an effective enterprise
architecture capability. The TOGAF standard also provides guidance on a process
that can be followed to identify and establish an appropriate architecture
capability.

What Kinds of Architecture does the TOGAF Standard Deal with?

Business Architecture - The business strategy, governance, organization, and key


business processes.

Data Architecture - The structure of an organization’s logical and physical data


assets and data management resources.

Application Architecture - A blueprint for the individual applications to be


deployed, their interactions, and their relationships to the core business
processes of the organization.

Technology Architecture - The logical software and hardware capabilities that are
required to support the deployment of business, data, and application services.
This includes IT infrastructure, middleware, networks, communications, processing,
and standards.

The TOGAF ADM phases are:

Preliminary Phase - Prepare the organization for successful TOGAF


architecture
projects. Undertake the preparation and initiation activities required to create an
Architecture Capability, including the customization of the TOGAF framework,
selection of tools, and the
definition of Architecture Principles.
Requirements Management - Ensure that every stage of a TOGAF project is based
on and
validates business requirements. Requirements are identified, stored, and fed into
and out of the
relevant ADM phases, which dispose of, address, and prioritize requirements.

Phase A: Architecture Vision - Set the scope, constraints, and expectations


for a TOGAF project. Create the Architecture Vision. Identify stakeholders.
Validate the business context and create the Statement of Architecture Work. Obtain
approvals.

Phase B: Business Architecture | Phase C: Information Systems Architectures |


Phase D:
Technology Architecture - Develop architectures in four domains:

1. Business
2. Information Systems – Application
3. Information Systems – Data
4. Technology

In each case, develop the Baseline and Target Architecture and analyze gaps.

Phase E: Opportunities and Solutions - Perform initial implementation


planning and the identification of delivery vehicles for the building blocks
identified in the previous
phases. Determine whether an incremental approach is required, and if so identify
Transition Architectures.

Phase F: Migration Planning - Develop detailed Implementation and Migration


Plan that
addresses how to move from the Baseline to the Target Architecture.

Phase G: Implementation Governance - Provide architectural oversight for the


implementation.
Prepare and issue Architecture Contracts. Ensure that the implementation project
conforms to the
architecture.

Phase H: Architecture Change Management - Provide continual monitoring and a


change management process to ensure that the architecture responds to the needs of
the enterprise, and maximizes the business value.

*** NOTE: the four commonly accepted subsets of an enterprise architecture


are:

Business Architecture - The business strategy, governance, organization, and key


business processes.

Data Architecture - The structure of an organization’s logical and physical data


assets and data management resources.
Application Architecture - A blueprint for the individual applications to be
deployed, their interactions, and their relationships to the core business
processes of the organization.

Technology Architecture - The logical software and hardware capabilities that are
required to support the deployment of business, data, and application services.
This includes IT infrastructure, middleware, networks, communications, processing,
and standards.

The Zachman framework - As postulated by the creator, John Zachman's Concise


Definition of The
Zachman Framework:

https://www.zachman.com/about-the-zachman-framework

"The Zachman Framework™ is a schema - the intersection between two historical


classifications that have been in use for literally thousands of years. The first
is the fundamentals of communication found in the primitive interrogatives: What,
How, When, Who, Where, and Why. It is the integration of answers to these questions
that enables the comprehensive, composite description of complex ideas. The second
is derived from reification, the transformation of an abstract idea into an
instantiation that was initially postulated by ancient Greek philosophers and is
labeled in the Zachman Framework™: Identification, Definition, Representation,
Specification, Configuration and Instantiation."

The Zachman Framework typically is depicted as a bounded 6 x 6 “matrix” with the


Communication Interrogatives as Columns and the Reification Transformations as
Rows. The Framework classifications are represented by the Cells, that is, the
intersection between the Interrogatives and the Transformations. This matrix would
necessarily constitute the total set of descriptive representations that are
relevant for describing something... anything...

Yeah... So what does that all really mean??!!

In the Zachman architecture model, IT systems and environments are described at a


high, functional level and then, in increasing detail, encompassing systems,
databases, applications, networks, and so on.

While the Zachman model allows an organization to peer into cross sections of an IT
environment that supports business processes, the model DOES NOT convey the
relationships between IT systems.

Data flow diagrams (DFD) are used instead to depict information flows. A DFD can
begin as a high-level diagram, where the labels of information flows are expressed
in business terms. Written specifications about each flow can accompany the DFD;
these specifications would describe the flow in increasing levels of detail, all
the way to field lengths and communication protocol settings.

Audience Perspectives:

• Executive
• Business Management
• Architect
• Engineer
• Technician
• Enterprise

Information Security Management Frameworks - representation of a security


management structure

• ISO/IEC 27001:2013 “Information technology – Security techniques – Information


security management systems – Requirements,” - defines the requirements and steps
taken to run an information security management system (ISMS), which is the set of
processes used to assess risk, develop policy and controls, and manage all of the
typical processes found in information security programs such as vulnerability
management and incident management.

• COBIT 2019 - a controls and governance framework for managing an IT organization.

• NIST Cyber Security Framework (CSF) - an outcomes-based security management and


control framework that guides an organization to understand its existing maturity
levels, assess risk, identify gaps, and develop action plans for strategic
improvement.

Components:

Framework Core
Framework Implementation Tiers
Framework Profile

• Risk Management Framework (RMF) -

The selection and specification of security controls for a system SHOULD BE


accomplished as part of an organization-wide information security program that
involves the management of organizational risk.

THE RISK MANAGEMENT FRAMEWORK PROVIDES A PROCESS THAT INTEGRATES SECURITY & RISK
MANAGEMENT ACTIVITIES INTO THE SYSTEM DEVELOPMENT LIFE CYCLE.

Risk-Based Approach -

The risk-based approach to security control selection and specification considers


effectiveness, efficiency, and constraints due to applicable laws, directives,
Executive Orders, policies, standards, or regulations.

The following activities related to managing organizational risk are paramount to


an effective information security program and can be applied to both new and legacy
systems within the context of the system development life cycle:
1. Prepare Step -

Prepare carries out essential activities at the organization, mission and business
process, and information system levels of the enterprise to help prepare the
organization to manage its security and privacy risks using the Risk Management
Framework.

2. Categorize Step -

Categorize the system and the information processed, stored, and transmitted by
that system based on an impact analysis (*1).

3. Select Step -

Select an initial set of baseline security controls for the system based on the
security categorization; tailoring and supplementing the security control baseline
as needed based on organization assessment of risk and local conditions.

4. Implement Step -

Implement the security controls and document how the controls are deployed within
the system and environment of operation.

5. Assess Step -

Assess the security controls using appropriate procedures to determine the extent
to which the controls are implemented correctly, operating as intended, and
producing the desired outcome with respect to meeting the security requirements for
the system.

6. Authorize Step -

Authorize system operation based upon a determination of the risk to organizational


operations and assets, individuals, other organizations and the Nation resulting
from the operation of the system and the decision that this risk is acceptable
(*2).

7. Monitor Step -

Monitor and assess selected security controls in the system on an ongoing basis
including assessing security control effectiveness, documenting changes to the
system or environment of operation, conducting security impact analyses of the
associated changes, and reporting the security state of the system to appropriate
organizational officials (*3).

Footnotes:

1. The RMF categorize step, including consideration of legislation, policies,


directives, regulations, standards, and organizational mission/business/operational
requirements, facilitates the identification of security requirements.

2. NIST Special Publication 800-37 Revision 2 provides guidance on authorizing


system to operate.

3. NIST Special Publication 800-37 Revision 2 provides guidance on monitoring the


security controls in the environment of operation, the ongoing risk determination
and acceptance, and the approved system authorization to operated status.

What are the components of the management framework?

1. Technical
2. Operational
3. Management
4. Administrative
5. Educational/Informative

===================

Information Security Policies Procedures & Guidelines

Security Policy - Direction from senior management (Strategic - Why & What)

Standard - Formalized (Regulatory / Statutory)

Process - A series of related tasks or methods that together turn inputs into
outputs. (Operational - Who & When & Where)

Procedure - Step by step method of accomplishing something (Tactical - How)

Guideline - Best Practice recommendation

A roadmap helps to develop a "stage by stage" view of a process to create


manageable pieces that contribute to the success of the entire efort.

The use of a lifecycle to support the roadmap is suggested, 5 phase SDLC:

1. Initiation
2. Development/Acquisition
3. Implementation
4. Operation/Maintenance
5. Disposal

=======================
Information Security Program Metrics

Metric - quantifiable entity that allows for measurement of progress to goal

Good metrics are SMART:

|S| pecfic
|M| easurable
|A| ttainable
|R| elavant
|T| ime bounded

Areas to focus on developing metrics for include:

1. Strategic alignment
2. Risk management
3. Value delivery
4. Resource management
5. Performance measurement

*** Metrics should be relevant to the organizations operational landscape --- ONE
SIZE FITS ONE

====================

Information Security Control Design & Selection

Controls are the means of managing risk, and are implemented to achieve particular
objectives... BUT... We need Policy, Process, Standards & Technology working
together to achieve ensure a successful defense

Countermeasure - control put in place against a specific threat

Control Methods/Categories:

• Physical
• Administrative
• Logical (Technical)

The seven main types of functional controls are:

1. Directive: attempt to specify action(s) to ensure compliance with security


policy
2. Deterrent: attempt to discourage security policy violations. Key
difference between Preventative and Deterrent is that preventative blocks action
while deterrent relies on individual making the right choice

3. Preventive: attempt to stop unwanted access

4. Compensating: attempt to provide an alternate control in absence of


primary

5. Detective: attempt to identify unauthorized access AFTER occurrence of


unauthorized activity

6. Corrective: modifies environment to return to normal operation AFTER


occurrence of unauthorized activity

7. Recovery: attempt to repair or restore after a security violation -


extension of corrective controls, but have more advanced capabilities

=======================

Control Implementation Integration Testing & Evaluation

Controls are the core element of the Information Security strategy implementation &
should be automated to prevent bypass

Principles that controls should embody:

Access Control
Secure Failure
Least Privilege
Compartmentalization
Segregation/Separation of Duties (SoD)
Transparency
Trust
Zero Trust

Security Orchestration, Automation, & Response (SOAR) -

SOAR platforms are a collection of software solutions and tools designed to browse
a broad range of sources and collect:

# Security threats
# Data
# Alerts

SOAR tools then analyze this disparate data through a combination of human and
machine learning to understand and prioritize incident response activities.

SOAR solutions can define your incident response procedures for you, by combining a
variety of data tasks including:
# Data gathering
# Case management
# Standardization
# Workflow
# Analytics

This format can then be handled by automated machine-driven activities.

What are the three security tasks that comprise SOAR?

1. Orchestration

Integrating a wide array of technologies and connecting security tools, both


security-specific and non-security specific, in order to make them work together
while improving security incident response times.

SOAR solutions can perform much more than ingesting and analyzing alerts from your
SIEM system. SOAR solutions can also ingest and analyze alerts from:

# User and entity behavior analytics (UEBA)


# Threat intelligence platforms
# Incident response platforms
# Intrusion detection and prevention systems (IDPS)

2. Automation

The machine-driven execution of security operations-related tasks. Tasks that were


previously performed by humans can be performed and standardized by SOAR solutions:

# Process steps
# Decision-making workflow
# Enforcement actions
# Status checking
# Auditing capabilities

3. Response

Security orchestration is pulling in and analyzing alerts from across your IT


infrastructure. Repetitive manual tasks are automatically designed and handled.

SOAR allows analysts to collaborate on incidents by extending their analysis


further than SIEM’s log data, further allowing these analysts to determine
remediation for potential vulnerabilities to prevent further attacks.

SOAR tools also include case management modules. These modules are useful in
communicating learnings and delivering threat intelligence, further improving
proactive response times to future attacks.

SOAR use cases:

A few examples of the most common use cases for SOAR are:
# Phishing emails
# Malicious network traffic
# Streamlining vulnerability management
# Meeting service level agreements
# Case management

Defined baseline security controls should be applied for ALL new system
deployments; adequate testing of baselines to ensure compliance is important !!!

REMEMBER THE GOAL OF CONTROL --> MINIMIZE RISK(S) TO ACCEPTABLE LEVEL

The strength of a control is based on its inherent strength & likelihood of


effectiveness; can be tested via internal or external activities such as
vulnerability and penetration assessments

Recommendation of controls for deployment should be based on the results of the


risk assessment & analysis processes, and provide input into the risk treatment
process; to be effective, control implementations should seek input from the
buisness owner

REMEMBER CHANGES TO OPERATIONAL LANDSCAPES = POTENTIAL CHANGES TO


CONTROLS

==============

Information Security Awareness & Training

Training & security awareness is only effective if it is ongoing and aligned with
the KGIs, KPIs & KRIs established

Training should encompass ALL current employees as well as vendors & suppliers as
appropriate

Role based training for security related jobs is important

Ensuring complete training coverage through the use of systems that allow for
tracking and reporting is important

Complete & accurate documentation of roles & responsibilities is also important

Information Security roles & responsibilities.docx


==============

Integration of Security Program with IT Operations

Guess what time it is boys and girls !!! Hint ... ---> GRC is a'comin'

Replay that beautiful GRC footage from Domain 1:

|
|
|
|
v

The purpose of security governance is to align the organization’s security program


with the needs of the business.

Information security governance refers to a collection of top-down activities


intended to control the security organization (and security-related activities in
every part of the organization) from a strategic perspective to ensure that
information security supports the business.

According to ISACA, "Governance ensures that stakeholder needs, conditions, and


options are evaluated to determine balanced, agreed upon enterprise objectives to
be achieved. Setting direction through prioritization and decision making, and
monitoring performance and compliance against agreed upon direction and
objectives."

??!! --> WHAT?

How about, according to Adam, "that Governance helps to ensure that the decisions
organizations make, having to do with security and risk, are well informed and meet
the stated goals and objectives all the way up and down the management structure."

Business Alignment involves understanding the organization’s highest-level guiding


principles including the following:

• Mission - Why does the organization exist? Who does it serve, and through what
products and services?

• Goals and objectives - What achievements does the organization want to


accomplish, and when does it want to accomplish them?

• Strategy - What are the activities that need to take place so that the
organization’s goals and objectives can be fulfilled?

Information security governance is focused on several key processes:

• Personnel Management
• Sourcing
• Risk Management
• Configuration Management
• Change Management
• Access Management
• Vulnerability Management
• Incident Management
• Business Continuity Planning (BCP)

PLUS:

The establishment of an effective organization structure and clear statements of


roles and responsibilities.

Effective governance programs will use a balanced scorecard, metrics, or other


means to monitor these and other key processes.

Through a process of continuous improvement, security processes will be changed to


remain effective and to support ongoing business needs.

What does Information Security Governance provide?

• Objectives - capabilities or end states, expressed in achievable,


measurable terms.

• Strategy - a plan to achieve one or more objectives. (think of it as a plan


to implement security reporting, management, risk assessment activities, incident
management activities, etc., all targeted to assist the organization with reaching
its goals)

• Policy - should directly reflect the mission, objectives, and goals of the
overall organization. Answers the "WHY" & "WHAT" questions.

• Processes - formalized descriptions of repeated business activities that


include instructions to applicable personnel. Processes include one or more
procedures, as well as definitions of business records and other facts that help
workers understand how things are supposed to be done.

• Controls - formal descriptions of critical activities to ensure desired


outcomes.

• Metrics/reporting - includes the formal measurement of processes and


controls so that management understands and can measure them.

So, what are the MAIN Security Governance Activities and the Results we can
expect???

REMEMBER that the organization’s senior management team is responsible for seeing
to it that information systems necessary to support business operations will be
adequately protected.

Activities required to protect the organization:

• Risk management

• Process improvement

• Event identification
• Incident response

• Improved compliance

• Business continuity and disaster recovery planning

• Metrics

• Resource management

Key results of an effective security governance program:

• Increased trust

• Improved reputation

Integration of security with the SDLC is PARAMOUNT !!!

Planning
Designing
Implementation
Testing & Integration
Maintenance

Waterfall & Agile are two of the best known development methodologies:

Waterfall - a sequential development approach, in which development is seen as


flowing steadily downwards (like a waterfall) through several phases, typically:

1. Requirements analysis resulting in a software requirements specification


2. Software design
a. High level design phase - list of functionality modules,
correlation modules, architecture diagrams, and database tables
b. Low level design phase - designing of the actual software
components, which will be used in the system
3. Implementation
4. Testing
5. Integration, if there are multiple subsystems
6. Deployment (or Installation)
7. Maintenance

Examples - Structured Programming

agile/Agile:
Practices involve discovering requirements and developing solutions through the
collaborative effort of self-organizing and cross-functional teams and their
customer(s)/end user(s). It advocates adaptive planning, evolutionary development,
early delivery, and continual improvement, and it encourages flexible responses to
change.
DevOps/DevSecOps/integrated product team - A combination of participants from
various functional areas (development, productions/operations, security, quality
assurance, management, etc.) involved in the overall development effort, intended
to ensure all functional and nonfunctional requirements are met during
software/system development

While it is very difficult to find an acceptable definition of just what DevOps is,
DevOps aims at shorter development cycles, increased deployment frequency, and more
dependable releases, in close alignment with business objectives.

Core concepts:

Develop and test against production-like systems


Deploy with repeatable, reliable processes
Monitor and validate operational quality
Communication with stakeholders enabling action on feedback

NOTE: DevOps is complementary with Agile software development; several DevOps


aspects came from the Agile methodology.

Continuous Integration and Continuous Delivery (CI/CD) -

CI/CD are two DevOps best practices as they tackle the misalignment between
developers and operational team. With the presence of automation, developers can
release changes and new features more frequently, while operation teams have better
overall stability.

What is Continuous Integration (CI)?

Helps ensure that software components work together. Integration should be


completed frequently; if possible, on an hourly or daily basis.

In a CI practice, developers build, run, and test code on their own workstations
before committing code to the version control repository. After changes are made to
the repository, a chain of events is put into motion.

A typical first step in this chain is to build the latest version of source code.

If the build is successful, unit tests are executed.

If unit testing succeeds, the build is deployed to test environments where system
tests are performed (usually using automated tests).

The team is notified about the status of this process, and a report is delivered to
provide details, such as build number, defects, and the number of tests.

A CI pipeline typically involves the following tasks:

# Detect changes in the source code repository (new commits appear)


# Source code quality analysis
# Build
# Execute all unit tests
# Execute all integration tests
# Generate deployable artifacts
# Report status

If one of the steps above fails:

# Integration may stop or continue depending on defect severity and


configuration
# Results are notified to the team via email or chat system
# Team fixes defects and commits again
# Tasks are performed again

What is Continuous Delivery (CD)?

Picks up where continuous integration ends. While CI is the process to build and
test automatically, CD deploys all code changes in a build to the testing or
staging environment.

CD makes it possible to release builds to the production environment when needed.


Allowing the team to deploy at will, CD effectively reduces time to market.

Before deploying software to production, the CD process includes performing


automated system testing, unit testing (including API testing and load testing),
and integration testing.

The steps from CI to CD are usually completed automatically, including automated


testing at the unit, integration, and system levels.

As tests can fail at any level and environment, CI/CD must include a feedback
channel to quickly report failures to developers.

Dependent on policies and processes defined by teams, developers may do the


following with CI/CD:

Step 1: Before committing changes, developers check to see if the current


build succeeded. If not, fix errors before committing new changes.

Step 2: If the current build succeeded, reset the workstation with the
build’s configuration.

Step 3: Build and test locally to ensure the update does not break any
functionality. If successful, commit new changes.

Step 4: Allow CI to complete with new changes.

Step 5: If the build fails, stop and fix errors on local workstations. Go
back to Step 3.

Step 6: If the build passes, continue working on other items.

What is a CI/CD Workflow Pipeline?


A CI/CD pipeline is a path for delivering a unit of change that starts from
development to delivery, usually consists of the following main phases:

Phase 1: Commit
When developers complete a change, they commit the change to the repository.

Phase 2: Build
Source code from the repository is integrated into a build.

Phase 3: Automate tests


Automated tests are run against the build. Test automation is an essential element
of any CI/CD pipeline.

Phase 4: Deploy
The built version is delivered to production.

IT Service Management (ITSM) - the set of activities that ensures the delivery of
IT services is efficient and effective, through active management and the
continuous improvement of processes. ITSM consists of several distinct activities:

• Service desk
• Incident management
• Problem management
• Change management
• Configuration management
• Release management
• Service-level management
• Financial management
• Capacity management
• Service continuity management
• Availability management

Service Desk = Single Point of Contact for ALL communication with customers

Incident = unplanned interruption to an IT Service or reduction in the quality of


an IT service

Known Error = incident that has a defined root cause

Problem = incident that has become systemic without becoming a known error

Types of Change Requests:

a. Normal
b. Standard / Pre-Authorized
c. Emergency

Gate Process - each step of the process undergoes formal review and approval before
the next step is allowed to begin

Its all about the linkages:


Change Management Linkage to Problem and Incident Management - changes should
reference specific incidents or problems so that those incidents and problems may
be properly closed once verification of their resolution has been completed.

Configuration Management Linkage to Problem and Incident Management - the problem


and incident management system should be able to access the CMDB to help IT
personnel determine whether incidents and problems are related to specific
configurations. This can be an invaluable aid to those who are seeking to determine
a problem’s root cause.

Configuration Management Linkage to Change Management - configuration management


tools are able to automatically detect configuration changes that are made to a
system, and as a result, it is possible to correlate changes detected by a
configuration management system with changes approved in the change management
process.

Capacity Management Linkage to Financial Management - One of the work products of


capacity management is a projection for the acquisition of additional computer or
network hardware to meet future capacity needs. This information needs to be made
part of budgeting and spending management processes.

Capacity Management Linkage to Service Level Management - If there are insufficient


resources to handle workloads, capacity issues may result in violations to SLAs.

Capacity Management Linkage to Incident and Problem Management - Systems with


severe capacity issues may take excessive time to respond to user requests, as a
result, users will call the service desk, resulting in the logging of incidents and
problems.

Change management - should have a formal cycle, in the same manner as the SDLC.

Key points of change management are that:

a. There is a rigorous process that addresses quality assurance

b. Changes must be submitted, approved, tested, and recorded

c. There should be a back-out plan in case the change is not successful

What is Configuration management?

Monitoring and managing changes to a program or documentation. Configuration


management drives information security and information assurance.

Configuration management ensures that various resources (servers, networks, mobile


devices, etc.), system services and applications are consistently configured and
always in compliance.

Configuration management is used to deploy changes (define desired states),


quickly, securely and consistently across any system regardless of scale (number of
units) and complexity (different architectures, operating systems, etc.).

Once a change has been deployed, it is the responsibility of the configuration


management system to ensure that the system maintains the new desired state over
time and safeguards configuration integrity.

The following practices improve the security of your application's configuration


management:

1. Secure your administration interfaces


2. Secure your configuration information / store (CMDB / CI's)
3. Maintain separate administration privileges
4. Use least privileged process and service accounts

What is Software Configuration Management (SCM)?

In Software Engineering, Software Configuration Management (SCM) is a process to


systematically manage, organize, and control the changes in the documents, codes,
and other entities during the Software Development Life Cycle.

SCM helps in identifying individual elements and configurations, tracking changes,


and version selection, control, and baselining.

The primary goal is to increase productivity with minimal mistakes.

SCM is part of cross-disciplinary field of configuration management and it can


accurately determine who made which revision.

What are the tasks in the SCM process?

# Configuration Identification
# Baselines
# Change Control
# Configuration Status Accounting
# Configuration Audits and Reviews

What is/does Managed services mean? (e.g., Software as a Service (SaaS),


Infrastructure as a Service (IaaS), Platform as a Service (PaaS))

Managed services - the practice of outsourcing the responsibility for maintaining


and operating a range of processes and functions in order to improve operations and
cut expenses.

Cloud-Based System Vulnerabilities - cloud computing has been formally defined by


U.S. NIST as: “… a model for enabling ubiquitous, convenient, on-demand network
access to a shared pool of configurable computing resources (e.g., networks,
servers, storage, applications, and services) that can be rapidly provisioned and
released with minimal management effort or service provider interaction. This cloud
model is composed of five essential characteristics, three service models, and four
deployment models.”
Five Essential Characteristics of Cloud Computing - NIST (SP 800-145) defines them
as:

1. On-Demand Self-Service - A consumer can unilaterally provision computing


capabilities, such as server time and network storage, as needed automatically
without requiring human interaction with each service provider.

2. Broad Network Access - Capabilities are available over the network and
accessed through standard mechanisms that promote use by heterogeneous thin or
thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

3. Resource Pooling - The provider’s computing resources are pooled to serve


multiple consumers using a multi-tenant model, with different physical and virtual
resources dynamically assigned and reassigned according to consumer demand.
Examples of resources include storage, processing, memory, and network bandwidth.

4. Rapid Elasticity - Capabilities can be elastically provisioned and


released, in some cases automatically, to scale rapidly outward and inward
commensurate with demand.

5. Measured Service - Cloud systems automatically control and optimize


resource use by leveraging a metering capability at some level of abstraction
appropriate to the type of service (e.g., storage, processing, bandwidth, and
active user accounts).

Cloud Service Models - three service models:

1. Software as a Service (SaaS) - The capability provided to the consumer is


to use the provider’s applications running on a cloud infrastructure. The
applications are accessible from various client devices through either a thin
client interface, such as a web browser (e.g., web-based e-mail), or a program
interface. The consumer does not manage or control the underlying cloud
infrastructure, including network, servers, operating systems, storage, or even
individual application capabilities, with the possible exception of limited user-
specific application configuration settings.

2. Platform as a Service (PaaS) - The capability provided to the consumer is


to deploy onto the cloud infrastructure consumer-created or acquired applications
created using programming languages, libraries, services, and tools supported by
the provider. The consumer does not manage or control the underlying cloud
infrastructure, including network, servers, operating systems, or storage, but has
control over the deployed applications and possibly configuration settings for the
application-hosting environment.

3. Infrastructure as a Service (IaaS) - The capability provided to the


consumer is to provision processing, storage, networks, and other fundamental
computing resources where the consumer is able to deploy and run arbitrary
software, which can include operating systems and applications. The consumer does
not manage or control the underlying cloud infrastructure but has control over
operating systems, storage, and deployed applications; and possibly limited control
of select networking components (e.g., host firewalls).

Cloud Deployment Models - four:


1. Private Cloud - the cloud infrastructure is provisioned for exclusive use
by a single organization comprising multiple consumers (e.g., business units). It
may be owned, managed, and operated by the organization, a third party, or some
combination of them, and it may exist on or off premises.

2. Community Cloud - provisioned for exclusive use by a specific community of


consumers from organizations that have shared concerns (e.g., mission, security
requirements, policy, and compliance considerations). It may be owned, managed, and
operated by one or more of the organizations in the community, a third party, or
some combination of them, and it may exist on or off premises.

3. Public Cloud - provisioned for open use by the general public. It may be
owned, managed, and operated by a business, academic, or government organization,
or some combination of them. It exists on the premises of the cloud provider.

4. Hybrid Cloud - a composition of two or more distinct cloud infrastructures


(private, community, or public) that remain unique entities but are bound together
by standardized or proprietary technology that enables data and application
portability (e.g., cloud bursting for load balancing between clouds).

NOTE: As cloud computing moves from infrastructure to platform to software, the


responsibility to implement effective security controls shifts away from the
organization and toward the cloud service provider. Called the Cloud shared
responsibility model.

Cloud computing is based on the use of virtualization technology.

The key component that makes virtualization possible is the use of a Hypervisor
(Virtual Machine Monitor). Types:

a. Type I - Native or Bare-Metal. Used for Server virtualization

b. Type II - Hosted on a client O/S

=====================================================================

Management of External Services

Service Providers
Outsourced Operations
Trading Partners
Merged & Acquired Enterprises

ALL NEED TO BE TREATED THE SAME ... RISK ASSESSMENT & DOCUMENTED
POLICY/STANDARDS/PROCEDURES & CLEAR RESPONSIBILITY

There will be a "disconnect" between the organization & the outsourced provider
vis-a-vis the assessment & defintion of risk (organization) AND the control
implementation & monitoring (outsourced provider)
---> The controls to be implemented MUST be defined in the
services contract

It is imperative that issues associated with compliance/governance/oversight are


addressed as part of the contract/SLA negotiations; specifc audit requiremenst
sould be adddressed and included such as ISO 27001 & SOC2.

Need a primer on SOC reports? ---> Read on below...

Spotlight on Service Organization Controls Reports (SOC)

American Institute of Certified Public Accountants (AICPA) released The Statement


on Standards for Attestation Engagements document 16 (SSAE 16) to provide a common
set of standards to replace older SAS 70 standard & to give auditors performing
assessments a way to standardize their activities.

Type I - provides a description of the controls provided by the audited


organization and the auditor opinion based on the description, BUT... does not
involve actual testing of controls. A Type I Report is specifically defined by the
SSAE 16 guidance as a “report on a description of a service organization’s system
and the suitability of the design of controls”, essentially, a determination of if
your company’s controls are designed appropriately. When performing a Type I
report, the auditors will test the design effectiveness of your company’s defined
controls by examining a sample of 1 item per control.

Type II - covers a minimum period of 6 months and requires testing of the


controls and an opinion from the auditor as to effectiveness based upon test

Type 1 vs. Type 2 Reports:

Do not confuse SOC 1 and SOC 2 with Type 1 and Type 2. Both a SOC 1 and a SOC 2 can
be either a Type 1 or Type 2. The key differences are:

Type 1 addresses the design of controls as of a point in time


Type 2 addresses the operating effectiveness of controls over a period of
time

Type 1 reports provide less comfort to the intended audience of the report
and are uncommon

Three types of Service Organization Controls Report (SOC):

NOTE: The trust services principles and criteria are now referred to as the trust
services criteria, and the principles are now referred to as the trust services
categories (not to be confused with the COSO principles).

SOC 1 reports -
SOC 1 reporting engagements provide user organizations with a strong sense of
comfort about the outsourced services performed by service organizations on their
behalf, which are relevant to their internal controls over financial reporting.

Purpose: Reports on the controls of the service organization that are


relevant to the user organization's internal controls over financial reporting

Scope: Controls related to the accuracy of financial data and information


technology general controls

Audience: User organization's financial executives, compliance officers and


financial statement auditors

SOC 2 and 3 reports -

Established to address other types of third-party risks outside of financial


reporting, SOC 2 and 3 reports provide user organizations with assurance over the
critical systems and sensitive data used to provide the outsourced services.
Typically, these reports are used to meet vendor risk management requirements that
customers may request surrounding security. While the two options have similar
scope, a SOC 3 has less detail and, therefore, typically provides less value to
report users.

SOC 2 reports - (Type 1 or Type 2)

Purpose: Reports on the effectiveness of the controls of the service


organization related to operations, based on the selected trust services criteria
(TSC)

Scope: Governance, operational and information technology general controls


that address one or more of the TSC categories: security, confidentiality,
availability, processing integrity and privacy

Audience: User organization's information technology executives, compliance


officers, vendor management executives, regulators, other specified parties and
appropriate business partners

Additional Criteria: SOC 2 reports can also include other suitable criteria,
such as HITRUST, the HIPAA Security Rule and others

The Trust Service Criteria, which SOC 2 are based upon, are modeled around four
broad areas: Policies, Communications, Procedures, and Monitoring.

SOC 3 reports - (Type 1 ONLY !!!)

Purpose: Same purpose as SOC 2 report

Information required: Same information as SOC 2 report, but with a less


detailed description of the controls of the service organization

Audience: Unrestricted and can be used by anyone who has the appropriate
understanding of the subject matter and who would like confidence in the controls
for the service organization
SOC 3 reports can be issued on one or multiple Trust Services principles (security,
availability, processing integrity, confidentiality and privacy) and allow the
organization to place a seal on their website upon successful completion.

=============================

Information Security Program Communications & Reporting

Total Quality Management (TQM) - A core definition of total quality management


(TQM) describes a management approach to long-term success through customer
satisfaction. In a TQM effort, all members of an organization participate in
improving processes, products, services, and the culture in which they work.

Here are the 8 principles of total quality management:

1. Customer-focused: The customer ultimately determines the level of quality.

2. Total employee involvement: All employees participate in working toward common


goals. (Self-managed work teams are one form of empowerment.)

3. Process-centered: A fundamental part of TQM is a focus on process thinking; The


steps required to carry out the process are defined, and performance measures are
continuously monitored in order to detect unexpected variation.

4. Integrated system: Although an organization may consist of many different


functional specialties often organized into vertically structured departments, it
is the horizontal processes interconnecting these functions that are the focus of
TQM.

• Everyone must understand the vision, mission, and guiding principles as


well as the quality policies, objectives, and critical processes of the
organization. Business performance must be monitored and communicated continuously.

• Every organization has a unique work culture, and it is virtually


impossible to achieve excellence in its products and services unless a good quality
culture has been fostered. Thus, an integrated system connects business improvement
elements in an attempt to continually improve and exceed the expectations of
customers, employees, and other stakeholders.

5. Strategic and systematic approach: This process, called strategic planning or


strategic management, includes the formulation of a strategic plan that integrates
quality as a core component.

6. Continual improvement: Drives an organization to be both analytical and creative


in finding ways to become more competitive and more effective at meeting
stakeholder expectations.

7. Fact-based decision making: Requires that an organization continually collect


and analyze data in order to improve decision making accuracy, achieve consensus,
and allow prediction based on past history.

8. Communications: Strategies, method, and timeliness.


Shewart/Demming cycle

|P| lan
|D| o
|C| heck
|A| ct

Vision --> Strategic Objectives --> CSFs --> KPIs --> Key
actions/changes

Security review - a less formal and less rigorous examination of one or more
controls, processes, or systems to determine their state.

Security audit - a more formal and more rigorous examination of one or more
controls, processes, or systems.

*** NOTE: An audit generally requires the presentation of evidence of control


design and effectiveness, where a review often does not.

During development of the security program, the Information Security Manager should
use a review prorcess similiar to an audit to assess the program at key points:

D Objective - what is to be determined by the review (dicatates the scope)


Scope - mapping of the objective to the aspect to be reviewed
Constraint - something that may impact the ability to conduct the review
Approach - bringing together objective, scope & constraints to achieve the
review
Result - an assessment of whether the review objective has been met

Security Audits - a security assessment performed by independent auditors

a. internal - performed by a team from within the organization, usually meant


for internal consumption; generally concentrate on the controls that are associated
with authorized and trusted actors (employees and other users such as contractors)
and the threats that may stem from misuse of resources.

b. external - performed by an outside auditing firm not connected with the


organization; focus on threats posed by external actors that seek unauthorized
access to organizational resources.

c. third-party - conducted by and/or on behalf of another organization, such


as a regulatory body; usually arranged to augment or provide auxiliary support to
internal/external testing methodologies retained within an organization. Third-
party assessments also provide the highest level of assurance of assessment
independence.
Security Testing - verifies that a control is functioning properly

Security Assessment - a comprehensive review of the security of a system,


application and / or environment. A detailed report delivered to senior management
is the expected outcome.

Verification - provides objective evidence that the design outputs of a particular


phase of the software development life cycle meet all of the specified requirements
for that phase. Software verification looks for consistency, completeness, and
correctness of the software and its supporting documentation as it is being
developed.

Validation - developing a “level of confidence” that the software or system meets


all requirements and user expectations as documented.

Compliance - is the process by which the security manager determines whether the
organization’s information systems, processes, and personnel adhere to applicable
policies, standards, regulations, and other requirements.

NIST SP 800-53A R5 - Security and Privacy Controls for Federal Information Systems
and Organizations is most recent official version.

Under R5 Assessments include four components:

a. Specifications - the documents associated with a system being audited

b. Mechanisms - the controls used to meet the specifications

c. Activities - carried out by people within the system

d. Individuals - the people that implement specifications, mechanisms and


activities

Audit - a set of activities that determine whether security safeguards are in place
and working properly.

Audit Objectives - the specific goals for an audit

Formal planning is required so that the organization successfully achieves the


objectives for an audit. The types of planning that are required include the
following:

• Purpose - The auditor and the auditee must establish a reason why an audit
is to be performed. --> WHY

• Scope - The auditor and the auditee must also establish the scope of the
audit. --> WHAT

• Risk analysis - The auditor needs to be familiar with the levels of risk
associated with the area(s) being audited. Two different perspectives of risk may
be needed:

a. the relative levels of risk among the different aspects of the


area(s) being audited so that audit resources can be allocated accordingly

b. the absolute level of risk across the entire area(s) being audited

• Audit procedures - The purpose and scope of the audit may help to define
the procedures that will be required to perform the audit

• Resources - The auditor must determine what resources are needed and
available for the audit

• Schedule - The auditor needs to develop an audit schedule that will give
enough time for interviews, data collection and analysis, and report generation

What types of audits can be undertaken?

The following are the types of audits:

• Operational audit - an examination of IT controls, security controls, or


business controls to determine control existence and effectiveness. The focus of an
operational audit is usually the operation of one or more controls, and it could
concentrate on the IT management of a business process or on the business process
itself.

• Financial audit - an examination of the organization’s accounting system,


including accounting department processes and procedures. The objective is to
determine whether business controls are sufficient to ensure the integrity of
financial statements.

• Integrated audit - combines an operational audit and a financial audit in


order for the auditor to gain a complete understanding of the entire environment’s
integrity.

• IS audit - a detailed examination of most or all of an information systems


(IS) department’s operations. An IS audit looks at IT governance to determine
whether IT is aligned with overall organization goals and objectives. The audit
also looks closely at all of the major IT processes, including service delivery,
change and configuration management, security management, systems development life
cycle, business relationship and supplier management, and incident and problem
management. This audit will determine whether each control objective and control is
effective and operating properly.

• Administrative audit - an examination of operational efficiency within some


segment of the organization.

• Compliance audit - performed to determine the level and degree of


compliance to a law, regulation, standard, internal control, or legal contract. If
a particular law or standard requires an external audit, the compliance audit may
have to be performed by approved or licensed external auditors.

• Forensic audit - performed by an auditor or a forensic specialist in


support of an anticipated or active legal proceeding. To withstand cross-
examination and to avoid having evidence being ruled inadmissible, strict
procedures must be followed in a forensic audit, including the preservation of
evidence and a chain of custody of evidence.

• Service provider audit - Because many organizations outsource critical


activities to third parties, often these third-party service organizations will
undergo one or more external audits to increase customer confidence in the
integrity and security of the third-party organization’s services.

• Pre-audit - an examination of business processes, information systems,


applications, or business records in anticipation of an upcoming audit. Usually, an
organization will undergo a preaudit to get a better idea of its compliance to a
law, regulation, standard, or other legal obligation prior to an actual compliance
audit. An organization can use the results of a pre-audit to implement corrective
measures, thereby improving the outcome of the real audit.

What is an Audit Methodology? - the set of audit procedures that is used to


accomplish a set of audit objectives. The phases of a typical audit methodology
are:

• Audit subject

• Audit objective

• Type of audit

• Audit scope - needs a time span to be applied to the audit subject to


ensure we examine the right things AND the right timeline

• Pre-audit planning

• Statement of Work (SOW) - describes the audit purpose, scope, duration, and
costs

• Audit procedures

• Audit communication plan

• Report preparation & Wrap up

• Post Audit Follow-up

What is Audit Evidence? - the information collected by the auditor during the
audit.

The contents and reliability of the evidence obtained are used by the auditor to
reach conclusions on the effectiveness of controls and control objectives.

When an auditor examines evidence, they need to consider several characteristics


about the evidence, which will contribute to its weight and reliability. These
characteristics include the following:

• Independence of the evidence provider


• Qualifications of the evidence provider
• Objectivity
• Timing

What is Control Self-Assessment (CSA)? - a methodology used by an organization to


INTERNALLY review key business objectives, risks related to achieving these
objectives, and the key controls designed to manage those risks.

CSA Advantages and Disadvantages:

Advantages of a control self-assessment include the following:

• Risks can be detected earlier, since subject-matter experts are involved


earlier

• Internal controls can be improved in a timely manner

• Control self-assessment leads to greater ownership of controls through


involvement in their assessment and improvement

• Control self-assessment leads to improved employee awareness of controls


through involvement in their assessment and improvement

• Control self-assessment may help improve relationships between departments


and auditors

Disadvantages of a control self-assessment include the following:

• Control self-assessment could be mistaken by employees or management as a


substitute for an internal audit

• Control self-assessment may be considered extra work and dismissed as


unnecessary

• Lack of employee involvement would translate to little or no process


improvement

The Control Self-Assessment Life Cycle - an iterative life cycle, made up of the
following phases:

• Identify and assess risks - operational risks are identified & analyzed

• Identify and assess controls - if any controls are missing, new controls
are designed

• Develop questionnaire or conduct workshop - an interactive session is


conducted, if possible, for discussion of risks and controls

• Analyze completed questionnaires or assess workshop

• Control remediation - using the best ideas from the workshop or


questionnaire, controls are designed or altered to better manage risk

• Awareness training - carried out through every phase of the life cycle to
keep personnel informed about the activities in the various phases

NOTE: The security manager and internal auditor should be involved in control self-
assessments to ensure that the CSA process does not try to remove controls from
processes because their purpose or significance is not correctly understood.

Why is the security policy SOOOOOOOOOO important? - security policy defines the
principles and required actions for the organization to properly protect its assets
and personnel.

The audience for security policy is ALL of the organization’s personnel, and
therefore, security policy must be easily accessible by all personnel.

The development of policy needs to incorporate several considerations, including


the following:

• ANY/ALL applicable laws, regulations, & standards


• Risk tolerance
• Controls
• Organizational culture

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy