[vc_row css_animation=”” row_type=”row” use_row_as_full_screen_section=”no” type=”full_width” angled_section=”no” text_align=”left” background_image_as_pattern=”without_pattern”][vc_column][vc_column_text]
The Information Assurance Program (IAP) is focused on pre-production testing. ComplianceForge’s IAP is based on established processes used by the US Government (e.g., FISMA, DIACAP, DIARMF) to validate the existence and functionality of controls, prior to a system, application or service going into production. In US Government language, this is commonly referred to as Certification & Accreditation (CA) or Security Testing & Evaluation (ST&E). We “civilianized” this concept of CA/ST&E to create a method to enable cybersecurity and privacy personnel to work with your organization’s existing System Development Life Cycle (SDLC) / Project Development Life Cycle (PDLC) to ensure privacy and cybersecurity principles are designed and built-into your systems, applications and services!
The end state with control validation testing is:
- Removal of “security roadblocks” by embedding cybersecurity and privacy into the SDLC/PDLC from project kick-off through the “go live” data.
- Having evidence of both cybersecurity and privacy principles being identified and implemented by design (e.g., EU GDPR compliance)
- Utilizing a customized control sets that defines Minimum Security Requirements (MSR) specific to the project undergoing review.
- A data-centric view across systems, applications, services and third-parties that enables situational awareness of both cybersecurity and privacy risks.
- A Project Risk Register (PRR) that tracks risks and the associated remediation actions (e.g., Plan of Action & Milestones (POA&M)).
- A formal method of getting stakeholder accountability for residual risk.
Why Should I Buy The IAP? What Actually Requires “Pre-Production Testing” To Be Performed?
As a CISO or CPO, performing IAP is not only the right thing to do from a security and privacy perspective, but it is serious job security. When things go bad and fingers get pointed, do you have a “get out of jail free card” that you can use? If not, keep reading.
A CISO or CPO should never make the decision to “sign off” and own risk, since it is ultimately a business decision and that director/VP of the business unit should be accepting the risk for their projects, services and vendors needed to operate. It is the responsibility of the CISO and CPO to have a data-centric view of risk from the application, system, service and supply chain perspective. With this understanding of the risks, the CISO and CPO need to educate the business process owners if minimum security requirements are/are not met and if the risk falls within the organization’s risk appetite. This is where the CRO role defines what is acceptable risk and works with the business units to get them to hopefully make the correct GO/NO GO decision. If they do choose to do something outside of the risk appetite, the CRO/CISO/CPO has evidence to demonstrate due care in their analysis. A lot of this requires a mature pre-production control validation testing process, which is absent in many organizations beyond a rudimentary security gate for change control.
The following are common statutory, regulatory and contractual requirements that expect “pre-production testing” or “information assurance” activities to be performed:
- ISO 27002 – 14.2.8
- European Union General Data Protection Regulation (EU GDPR) – Article 25
- NIST 800-171 – 3.12.1, 3.12.3 & Non-Federal Organization (NFO)
- NIST Cybersecurity Framework – PR.IP-2, PR.IP-5 & DE.DP-3
- Federal Risk and Authorization Management Program (FedRAMP) – Security Assessment & Authorization (CA) controls
- AICPA Trust Services Principles (TSP) SOC2 – CC7.4
- Center for Internet Security Critical Security Controls (CIS CSC) – 18.2, 18.4 & 18.8
- Cloud Security Alliance Cloud Controls Matrix (CSA CCM) – CCC-03
- Cloud Computing Compliance Controls Catalogue (C5) – BEI-02
- Monitory Authority of Singapore Technology Risk Management (MAS TRM) Guidelines – 6.0.1, 6.2.2, 6.2.3, 6.2.4, 6.3.4, 6.4.2, 6.4.3, 6.4.4, A.1.1 & A.1.2
- European Union Agency for Network and Information Security (ENISA) Technical Guideline of Security Measures – SO23
- National Industry Security Program Operating Manual (NISPOM) – 8-610 & 8-302
- Criminal Justice Information Services (CJIS) Security Policy – 220.127.116.11, 18.104.22.168, 22.214.171.124, 5.11.2 & 126.96.36.199
- Massachusetts MA 201 CMR 17.00 – 17.03(2)(d)(B)(i) & 17.03(2)(h)
- New York Department of Financial Services (23 NYCRR 500) – 500.02
- Oregon Consumer Identity Theft Protection Act (OCITPA) – 622(2)(B)(i)-(iv)
- Underwriters Laboratories (UL) 2900-1 – Section 12
- Payment Card Industry Data Security Standard (PCI DSS) – Requirement 6
- Motion Picture Association of America (MPAA) Content Security Program – MS-2.0