Security Architecture
What is it? How to deploy it?

PCI Software Security
Framework
June 28, 2023
Miguel (Mike) O. Villegas
CISO, CTO, CISSP, CISA, CDPSE, CEH,
CSX|F, CSX|A, ISO27001 Lead Implementer
mike.villegas@isecureprivacy.com
213.453.6174

Cybersecurity Architecture
Cybersecurity architecture is the discipline of planning out strategically the security
measures of the organization.
Cybersecurity architects create a blueprint on how these security measures are
effectively planned, designed, justified, tested, deployed, measured, andmaintained.
There are also different kinds of architects that play a role in deploying acybersecurity architecture. These include:• system architects,• application architects,• network architects,• cloud architects,• software architects,• data architects, and several others.
2Architect

Architect
Noun. /’a(r)ki,tekt/
1. A professional who sleeps 2 hours a day
2. Gets excited by details no one cares about
3. Need to do precision work based on questionable client information
4. Solves a problem you did not know you had, in a way you do not understand3

Architect (Really)

Architect
Noun. /’a(r)ki,tekt/
1. Design: Creates the overall concept and layout of a structure
2. Planning: Determines what is needed, what cannot be done, what is required
3. Technical: Provides guidance on construction methods, materials, techniques
4. Project Management: Is the PM or works closely with PMs to oversee
implementation of design
5. Collaboration: Works closely with clients, engineers, designers, developers, andstakeholders
4Cybersecurity Architect

Do you have a Cybersecurity Architect?
If you do, that is AWESOME!!!
If you do not, guess what? You ARE the Cybersecurity Architect!!

5Information Security and Cybersecurity
Information Security refers to the practice of protecting information and information
systems from unauthorized access, use, disclosure, disruption, modification, or destruction.
It covers all types of information, including electronic and physical, and includes policies,
procedures, and controls to ensure the confidentiality, integrity, and availability of
information.
Cybersecurity specifically focuses on protecting information and information systems fromcyber threats, which include computer viruses, malware, phishing attacks, hacking, andother malicious activities carried out through the internet and other electronic
communication channels. Cybersecurity involves protecting networks, devices, and datafrom unauthorized access, modification, or destruction.

6

Define Cybersecurity Architecture

Cybersecurity architecture refers to the design and implementation of acomprehensive security framework that protects an organization's networks,systems, and data from cyber threats.
Cybersecurity architecture typically includes several layers of security
controls that work together to create a defense-in-depth approach tosecurity.

7

Approaches to Security

•
•
•
•
•

Security through Obscurity – if no one knows how to use the system, no
one will know how to hack it
Security through Obsolesce – using very old antiquated products in thehopes that no one knows what to do with it.
Security through Minority – use the least number of products such thatthose with the skills required to use them are low.
Security through Diversity – use as many systems as possible so thatno one person knows all the systems used.
Security by Design – the best approach to Security; consider security inall phases.

8

Approaches to Security

IGNORANCE IS NOT A CONTROL

9

3 Principles of Architecture Design
Over the years, I have determined there are three basic principles of anarchitecture (or any system) design:Villegas

OWASP SAMM

Comprehensive

Measurable

Flexible

Actionable

Easy to Use

Versatile

These almost sound oxymoronic and difficult to achieve but if wellthought out, in aggregate they are achievable.

10

5W1H Problem Solving Approach
5W1H
What?

Business, Industry, Scope, Architecture

Where?

Legacy, Cloud, Outsourced

Why?

Growth, Compliance, Client-Driven, Targets

Who?

Internal, Customers, Vendors, Partners, Biz CultureWhen?

1-3-5 Year Plan, Aligned with Biz Strategy, YesterdayHow?

CSP SaaS, IaaS, PaaS; Dev Internally, Outsourced, MSP

As you review, design, deploy, or audit a security architecture, you need to ask these six questions at every step.

11

Security Architecture Frameworks and Security Frameworks
Security Architectures

Security Frameworks• SABSA (Sherwood Applied Business
Security Architecture)• CISSP – ISSAP (Information Systems Security
Architecture Professional) – 6 domains• OWASP SAMM (Software Assurance
Maturity Model)• PCI Software Security Framework (SSF)• NIST Cybersecurity Framework (CSF)• NIST SP 800-160 Engineering Trustworthy
Secure Systems• AWS Security by Design Framework• COBIT by ISACA (7 Domains)

1.
2.
3.
4.
5.
6.

Access Controls Systems & Methodology
Communications & Network Security
Cryptography
Security Architecture Analysis
Technology Related BCP & DRP
Physical Security Considerations

1.
2.
3.
4.
5.
6.
7.

Audit & Assurance
Emerging Technology
Governance
Information Security
Information Technology
Privacy
Risk• Microsoft Cybersecurity Reference
Architecture (MCRA)

12OWASP SAMM v2.0

The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate
and implement a strategy for software security that is tailored to the specific risks facing the organization.

ScopeIn-Scope includes• devices (technology)• processes• and people

Factors for Scope:• Tier 1 – used to store, process, or traverses through devices, processes, or people• Tier 2 – connected to, or has an impact on security of Tier 1

For example: Active Directory, NTP, SIEM, FIM, DNS

14

ScopeCritical Risk Data (CRD)

15

Operational Security

Operation’s View

SABSA Model for Security Architecture Development
Contextual Security

Business View

Conceptual Security

Architect’s View

Logical Security

Designers View

Physical Security

Builder’s View

Component Security

Engineer’s View

Source: Sherwood, Nicholas A. Enterprise Security Architecture: A Business-Driven Approach (p. 2). CRC Press. Kindle Edition.

16

36-Cell SABSA Matrix
Assets(What)

Motivation(Why)

Process(How)

People(Who)

Location(Where)Time(When)

Contextual

The BusinessBusiness Risk
Model

Business Process
Model

Business
Organization and
Relationships

Business
Geography

Business Time
Dependencies

Conceptual

Business
Attributes Profile

Control Objectives

Security Strategy
and Architectural
Layering

Security Entity
Model and Trust
Framework

Security Domain
Model

Security-Related
Lifetimes andDeadlines

LogicalBusiness
Information
Model

Security Policies

Security Services

Entity Schemas
and Privilege
ProfilesSecurity Domain
Definitions andAssociations

Security
Processing Cycle

PhysicalBusiness Data
Model

Security Rules,
Practices andProcedures

Security
Mechanisms

Users,
Applications andUser Interfaces

Platform andNetwork
Infrastructure

Control Structure
Execution

Component

Detailed Data
Structures

SecurityStandards

Security Products
and Tools

Identities,
Functions,
Actions, and
ACLs

Processes,
Modes,
Addresses andProtocols

Security Step
Timing andSequencing

Operational

Assurance ofOperational
Continuity

Operational Risk
Management

Security Service
Management andSupport

Application and
User
Management
SupportSecurity of Sites,
Networks andPlatforms

Security
Operations
Schedule

Source: Sherwood, Nicholas A. Enterprise Security Architecture: A Business-Driven Approach (p. 2). CRC Press. Kindle Edition.

17

PCI Secure Software Framework (SSF)

PCI Secure Software Framework (SSF)
Secure SLC Control Objectives

Secure Software Control Objectives

CO1: Security Responsibilities and Resources

CO1: Critical Asset Identification

CO2: Software Security Policy & Strategy

CO2: Secure Defaults

CO3: Threat Identification & Mitigation

CO3: Sensitive Data Retention

CO4: Vulnerability Detection & Mitigation

CO4: Critical Asset Protection

CO5: Change Management

CO5: Authentication & Access Control

CO6: Software Integrity Protection

CO6: Sensitive Data Protection

CO7: Sensitive Data Protection

CO7: Use of Cryptography

CO8: Vendor Security Guidance

CO8: Activity Tracking

CO9: Stakeholder Communications

CO9: Attack Detection

CO10: Software Update Information

CO10: Threat & Vulnerability Management
CO11: Secure Software Updates
CO12: Software Vendor Implementation GuidancePCI Secure Software Assessment Modules
Module A – Account Data Protection Requirements
COA.1: Sensitive Authentication Data
COA.2: Cardholder Data Protection
Module B – Terminal Software Requirements
COB.1: Terminal Software Documentation
COB.2: Terminal Software Design
COB.3: Terminal Software Security Testing
COB.4: Terminal Software Security Testing
COB.5: Terminal Software Implementation Guidance
Module C – Web Software Requirements
COC.1: Web Software Components & Services
COC.2: Web Software Access Controls
COC.3: Web Software Attack Mitigation
COC.4: Web Software Communications

PCI SSF Modules

Module A deals with security requirements for software that stores, processes, or transmits
account data

Module B deals with security requirements for software intended for deployment and execution
on PCI-approved POI devices. Point of Interchange (POI) would be for example point-of-sale (POS)
devices.

Module C deals with security requirements for payment software that uses Internet technologies,
protocols, and languages to initiate or support electronic payment transactions. This includes both:• Traditional (monolithic) web payment applications• Cloud-native payment applications

21

PCI Account Data
Account Data
Cardholder Data includes:

Sensitive Authentication Data includes:•

Primary Account Number (PAN)••

Cardholder Name•

Full track data (magnetic-stripe data orequivalent on a chip)
CAV2/CVC2/CVV2/CID•

Expiration Date•

PINs/PIN blocks•

Service CodePAN Obfuscation•

Encryption

Implies it can be decrypted•

Truncation

1234-56**-****-7890 (first 6; last 4)•

Hashing

One way hashing with salt; need strong algorithm not subject to rainbow•

Tokenization

Data replaced by surrogate, proxy values or tokens•

Masking

Data displayed in viewing or entering (first 6; last 4)

PCI Account Data
Encryption•

Storage

Hard disks, tape drives, databases, removables (e.g., thumb drives, DVD)•

Network

TLS 1.2+; VPN; MFA•

End-to-End

Encryption by default over the entire lifecycle; difficult since it relies ontrust relationships between systems•

Point-to-Point•

Application Layer

PCI encryption standard – PAN encrypted with an approved secure
cryptographic device (SCD) like POS and not decrypted at all at merchantLayer 7 (human interaction layer); 5W1H controls•

Full-Disk
Encryption

FDE protects from a disk being used in an unauthorized environment, butfile, field, database, and selective data encryption still needed•

Hardware Security
Module

HSM are hardened, tamper-resistant hardware devices to strengthen
encryption of data and/or key generation and key managementOWASP SAMM v2.0

The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate
and implement a strategy for software security that is tailored to the specific risks facing the organization.

SAMM - Governance25

SAMM - Governance

Governance – how an organization manages and measures overall software development
activities. It includes•

Policies•

Procedures•Compliance to laws••

Regulations
Internal PnP (polices and procedures)•

Training•

Awareness

26

Document Types
Type

Description

Policies

Communicate required and prohibited activities and behaviors

Standards

Interpret policies in specific situations

Procedures

Provide details on how to comply with policies and standards

Guidelines

Provide general guidance on issues such as “what to do inparticular circumstances.” These are not requirements tobe met, but are strongly recommended.
27

COBIT 5 Information Security Policy Set

Other Info Sec Related Policies
v Access Control Policyv Acceptable Use Policyv Data Retention Policy
v Personnel Information Security Policyv Social Media Policyv Wireless Policy
v Privacy Policyv Security Incident Response Policyv Security Awareness Policy
v Key Management Policyv Remote Access Policy
v Network Security Configuration Policy
v Server Security Configuration Policyv Secure Coding Standards
v Change Control Policy
v Physical Security Policyv Wireless Policy
v Many more…
28

Software Development Life Cycle (SDLC)
Stage 1: Plan and brainstorm.
Stage 2: Analyze requirements.

If you have 1 hour tochop down a tree,
you should spend
45 minutes
sharpening your ax

Stage 3: Design the mockups.
Stage 4: Develop the code.
Stage 5: Test the product.
Stage 6: Implement and launch the product.
Stage 7: Set up maintenance and operations.

29Contextual Security Architecture (Business View)
What is the business model and industry?
How is cybersecurity valued by business?

What are the business communication
requirements?
Info Sec has no intrinsic value on its own

Info Sec should be a business enabler

Does the business have a documented Strategic
Business Plan?

Does the business need online access, memo
posted, or legacy data to run their business?
Is remote access a requirement?

Does Info Sec have a documented Security
Strategic Plan?
Are these two strategic plans aligned?

Is the business dependent on successful
management of the supply chain?

Does the business work with and share PII, PHI,
PCI, M&A data with other entities (internal,
external, government)?

Is the Internet and web frequently used forresearch and information gathering?

How important are: customer service, market
reputation, management control, profit, regulatorycompliance?

Is the business dependent on authenticatedservice providers for source of information?

What are the applications that drive the businessand their related security needs?
30

ARE THE RIGHT PEOPLE IN CHARGE?

SAMM - Design

32

SAMM - Design
Design – how an organization defines goals and creates software within development projects.
•

How will the development project deal with real threats in applications?

•

What are the security requirements for the software and software suppliers (vendors or internal),
for example PCI SSF?

•

What are the architectural risks?
• security principles include defense in depth,• securing the weakest link,• use of secure defaults,• simplicity in design of security functionality,• secure failure,• balance of security and usability,• running with least privilege,• avoidance of security by obscurity - if no one knows how to use the system, no one will know
how to hack it
33

Conceptual Security Architecture (Architect’s View)
Supported Technologies: AI, satellite, RFID,
Obtain a comprehensive physical and logical network
HSM, FIM, SIEM, CSP, SOC, MSP, MSSP, etc. diagram.
Define the Business Attributes
Obtain data flow diagrams for each critical businessprocess, including IT.
Obtain a full inventory of the following assets: Define overall control objectives for each critical asset.
•

Critical risk data

Develop a multi-layered security model•Business and critical applications

Design security for each asset using 5W1H•

Complete list of hardware devices: layer-3,
servers, mobile, end-points, etc..

Identify all security services for each critical asset:
IAAA.

•

List of users, business groups, IT support,
Information Security
MSP, CSP, MSSP and any other service
provider(s)Perform an Enterprise Risk Assessment

I – Identification; A – Authentication; A –Authentication; A – Audit (logging and monitoring)
Design CIA into the Security Architecture Model••

Use Multi-Factor Authentication where needed

Goal is to design the forest and not the trees.
34Sensitive Data
PCI SSF CO1.1 All sensitive data stored, processed, or transmitted by the software is identified.
•

all payment data (PII, ePHI, PCI, critical risk data)•authentication credentials (passwords, tokens, certificates, DEKs, KEKs)•

cryptographic keys and related data (such as IVs and seed data for random number generators);•

system configuration data such as:• registry entries,

•

•

•

platform environment variables,•

prompts for plaintext data in software allowing for the entry of PIN data, or configuration
scripts.

Where is it stored• Temporary storage (volatile memory)•Semi-permanent storage (RAM)•Non-volatile storage (flash drives and flash storage media)

How is it protected•

Cryptography

•

ACL.

•

Protected memory.

• HSM
35

Web Software Components and Services
Modern software is rarely created entirely in-house and is typically composed of various bespoke
code segments that are integrated with numerous components. The following software
components need to be identified, verified, and tested for vulnerabilities:• All proprietary software libraries, packages, modules, and/or code packaged in a manner thatenables them to be tracked as a freestanding unit of software.
•

All third-party and open-source frameworks, libraries, and code embedded in or used by thesoftware during operation.

•

All third-party software dependencies, APIs, and services called by the software during
operation.

NIST refers to “provenance data” as information of the above components and services, versions,and any third-party code that may be embedded in these components.
The following shows how this information should be structured:•

CycloneDX

•

SPDX.

•

SWID
36

The software does not disclose sensitive data through unintended channels.
•

Error messages, error logs, or memory dumps.

•

Execution environments that may be vulnerable to remote side-channel attacks to expose
sensitive data•

Automatic storage or exposure of sensitive data by the underlying execution environment, suchas through swap-files, system error logging, keyboard spelling, and auto-correct features•

Sensors or services provided by the execution environment that may be used to extract or leaksensitive data such as through use of an accelerometer to capture input of a passphrase to be
used as a seed for a cryptographic key, or through capture of sensitive data through use ofcameras, near-field communication (NFC) interfaces

37

IF YOU DO NOT NEED IT
DO NOT STORE IT
AND SECURELY WIPE

38

SAMM - Implementation

39

SAMM - Implementation
Implementation – how an organization builds and deploys software components
and related defects.
• What external libraries does it use and how secure are they, such as open
source?
• Do you use automated security checks (such as DAST/SAST tools) in thepipeline to development?
• How do you handle code signing?

40

SAMM - Implementation

SAST Tools (Sample)
1.Synopsys (Coverity)

DAST Tools (Sample)
1.Rapid7 (AppSpider)

2.Checkmarx
3.Veracode
4.SonarQube

2.Acunetix
3.Micro Focus (Fortify WebInspect)
4.OWASP ZAP

5.Micro Focus (Fortify Static CodeAnalyzer)
6.Klocwork

5.Trustwave (App Scanner)
6.PortSwigger (Burp Suite)

41

Logical Security Architecture (Designer’s View)
Flesh out the bones of the Conceptual
Framework

Define interdependencies between systems andapplications

Develop information security policies,
procedures, and standards
Design security services into thesearchitectures:

Define access to assets based on Principle of Least
Privilege and RBAC
Identify solutions (products, services, and processes)
for IAAA for each critical asset•

Certificate management

Perform a Gap Assessment, controls not in place:•Directory services•

Inherent limitations•

Access control•

Lack of resources (time, people, funds)•

Entity authentication•

Lack of knowledge•

Service management•

Lack of management support•

Incident response

Perform Privacy Impact Assessment

Perform compliance reviews (SOC2, HIPAA,
ISO 27001, NY DFS, NIST SP 800 53/171
etc.)

Perform Business Impact Assessment

42

Multifactor Authentication
MFA (Multifactor Authentication) or Two-Factor Authentication should be used to strengthen
authentication controls for remote access. This currently is a requirement in some regulatory
and payment system security requirements.
Authentication Factors
v Something I knowv Something I havev Something I am

Logging on twice with an ID and password is
NOT MFA

SAMM - Verification

44

SAMM - Verification
Verification – this involves quality assurance work such as testing, compliance, documentation,
evaluation activities, and approvals. Verification of:• Architecture - Review the effectiveness of the architecture components and their provided security
mechanisms in terms of alignment with the overall strategy of the organization, and scrutinize thedegree of availability, scalability and enterprise readiness of the chosen security solutions.
• Requirements driven testing –• positive testing (control verification) which validates security controls are being met andprevents bugs being introduced into the application environment through regression testing,and• negative testing (misuse/abuse) which includes fuzzing (consists in finding implementation
bugs using malformed/semi-malformed data injection in an automated fashion; inserting
arbitrary code or wrong data types), misuse/abuse cases (consists of logical attacks that
ensures nothing happens that should not be allowed; for example, reasonable checks, DOS
attacks, business logic testing) https://github.com/samhocevar/zzuf/releases• Security testing – baseline testing using Static Applications Security Testing (SAST), Dynamic
Application Security Testing (DAST) or Interactive Application Security Testing (IAST) which is ahybrid of both SAST and DAST that combines the strength of both.
45

Controls to Mitigate Software Attacks
Examples of software security controls include:• Input and output validation• Authentication and Password Management
•
•
•
•
•

Parameterization
Escaping
Segmentation
Logging
Defaults modified

SECURE CODING STANDARDS• Encryption• Detection of anomalous behavior

46

Input Validation Guidelines (sample)• Conduct all data validation on a trusted system (e.g., The server)• Identify all data sources and classify them into trusted and untrusted. Validate all data from untrusted
sources (e.g., Databases, file streams, etc.)• There should be a centralized input validation routine for the application• Specify proper character sets, such as UTF-8, for all sources of input• Encode data to a common character set before validating (Canonicalize)• All validation failures should result in input rejection• Determine if the system supports UTF-8 extended character sets and if so, validate after UTF-8 decoding iscompleted• Validate all client provided data before processing, including all parameters, URLs and HTTP header
content (e.g. Cookie names and values). Be sure to include automated post backs from JavaScript, Flash orother embedded code
• Verify that header values in both requests and responses contain only ASCII characters• Validate data from redirects (An attacker may submit malicious content directly to the target of theredirect, thus circumventing application logic and any validation performed before the redirect)• Validate for expected data types• Validate data range• Validate data length
47

Authentication and Password Management Guidelines (sample)
•
•
•
•
•
•
•
•

•
•
•

Require authentication for all pages and resources, except those specifically intended to be public
All authentication controls must be enforced on a trusted system (e.g., The server)
Establish and utilize standard, tested, authentication services whenever possible
Use a centralized implementation for all authentication controls, including libraries that call external
authentication services
Segregate authentication logic from the resource being requested and use redirection to and from thecentralized authentication control
All authentication controls should fail securely
All administrative and account management functions must be at least as secure as the primaryauthentication mechanism
If your application manages a credential store, it should ensure that only cryptographically strong oneway salted hashes of passwords are stored and that the table/file that stores the passwords and keys iswrite-able only by the application. (Do not use the MD5 algorithm if it can be avoided)
Password hashing must be implemented on a trusted system (e.g., The server).
Validate the authentication data only on completion of all data input, especially for sequential
authentication implementations
Authentication failure responses should not indicate which part of the authentication data wasincorrect. For example, instead of “Invalid username” or “Invalid password”, just use “Invalid username
and/or password” for both. Error responses must be truly identical in both display and source code48

Trust, but Verify

Trust
VerifyVerifyTrust

49

Industry-Standards Bodies Key Management Controls• KEK must not be less than the DEK (e.g., by encrypting a 256-bit AES key with a
128-bit AES key).
• Any public keys are used by the system in an inventory and the authenticity of all
public keys is maintained.
• Where public or white-box keys are not unique per software instantiation,
methods and procedures to revoke and replace such keys (or key pairs) exist.
• Any external files or other data elements relied upon for key material (e.g., public
TLS certificates), must have clear and sufficient guidance on secure installation
provided by the vendor.
• Public keys manually loaded or used as root keys are installed and storedrequiring dual control preventing a single user from replacing a key.
• Secret and/or private keys are managed in a way that ensures split knowledge.
• Methods are implemented to "roll" any keys at the end of their defined cryptoperiod.
50

Physical Security Architecture (Builder’s View)
Focus on the data.

Security Baselines/Hardening Guides

Physical data management includes:•

Layer-3 (firewalls, routers, switches)•

File structures, including record and fieldstructures
File management tools, including directory
management••

Servers (web, application, database, DC, NTP,
etc.)
Operating systems•

Database structures•

Database systems

•

DBMSs

Perform periodic firewall (layer-3) rules review monthly, quarterly, annual, major infrastructure change
Perform user certification reviews - monthly•

Encryption/cryptographic and key
management procedures
Database Security
Perform Threat Analysis

Perform privileged user certification reviews –monthly, quarterly
Implement SIEM, FIM, AV, WAF alerting withcorrelation rules and monitoring
51

SAMM - Operations

52

SAMM - Operations
Operations – this involves activities necessary to ensure confidentiality, integrity, and availability(CIA) are maintained throughout the operational lifetime of an application and its associated data.
• Incident Management - This practice addresses activities carried out improve theorganization’s detection of, and response to, security incidents.
• Environment Management - This practice describes proactive activities carried out toimprove and maintain the security of the environments in which the organization's
applications operate.
• Operational Management - This practice focuses on operational support activities
required to maintain security throughout the product lifecycle.

53Component Security Architecture (Engineer’s View)

Focus on the tools.
Decide on Security Standards
•

ISO

•

ISACA

•

CIS

•

NIST

•

OWASP

•

PCI SSF

Decide on Security Products and Tools

Source: Sherwood, Nicholas A. Enterprise Security Architecture: A Business-Driven Approach (p. 2). CRC Press. Kindle Edition.

54

Multi-Layered Security Model

Defense in Depth56

Interdependencies
Modern IT architectures are usually decentralized and deperimeterized,
increasing security risk across several fronts, including:• Cloud-based platforms and services• Smart and mobile devices• Third-party products and services• Weak and unsecured parts of the IT architectureThis interdependent environment means control has been reduced—a changewith important impacts on security architecture.

57

Common Threat Agents

Source: Marinos, Louis, A. Belmonte, E. Rekleitis, “ENISA Threat Landscape 2015,” ENISA, January 2016, Greece
58Generative AI• Google’s Bard - ChatGPT’s main competitor is Bard, Google’s AI generative AI chatbot. Now
Google plans to add Bard into search. In comparison to ChatGPT• Baidu’s Ernie - The Chinese search engine Baidu plans to add a chatbot called Ernie. Baidu
announced the upcoming change on March 16, 2023, at which point the initial showing
disappointed investors.
• DeepMind’s Sparrow - DeepMind focuses more on research and has not yet come out with apublic-facing chatbot. DeepMind does have Sparrow, a chatbot designed specifically to help AI
communicate in a way that is “helpful, correct and harmless.” DeepMind founder Demis
Hassabis told The Independent in January 2023 that DeepMind may release a private beta
version of Sparrow later in 2023.
• Meta’s BlenderBot - Meta released BlenderBot in August 2022. The prototype BlenderBot
from the company behind Facebook focuses on being able to chat, providing short,conversational replies rather than full paragraphs.
• What about Apple? - According to The New York Times, Apple is working on leveraging thetech it has, especially Siri, to create a ChatGPT rival. More information about what the final
product might look like is thin on the ground for now.

OpenSource Risk
Fake Researcher Profiles Spread Malware through GitHub Repositories as PoC Exploits
June 14, 2023
https://thehackernews.com/2023/06/fake-researcher-profiles-spread-malware.html
At least half of dozen GitHub accounts from fake researchers associated with a fraudulent
cybersecurity company have been observed pushing malicious repositories on the code hosting
service.
All seven repositories, which are still available as of writing, claim to be a proof-of-concept (PoC)
exploit for purported zero-day flaws in Discord, Google Chrome, and Microsoft Exchange Server.
VulnCheck, which discovered the activity, said, "the individuals creating these repositories haveput significant effort into making them look legitimate by creating a network of accounts and Twitter
profiles, pretending to be part of a non-existent company called High Sierra Cyber Security."60

Security Standards• International Organization for Standards(ISO) 27000• Center of Internet Security (CIS)• International Security Forum (ISF)• ISACA COBIT• PCI Secure Software Framework (PCI SSF)
• The World Wide Web Consortium (W3C)• Internal Security Standards (your company)• OWASP Top 10• Vendor Standards• Common Weakness Enumeration (CWE)• US Federal Government (NIST)

61

Why Security Requirements Are Hard
1. Internally developed solutions are superior (pride/narcissism)
2. Jealous that proposed solutions is better than the one internally developed (jealous)
3. A prophet is not accepted in his own country (lack of respect)
4. Fear of looking bad or being embarrassed for internal solution (fear of being embarrassed)
5. They just don’t like you (previous experience with you or inherently who you are – e.g.,
auditor)6. What they do is all they know (hammer-vs-nail)7. Participants suffer from the NIH Syndrome62Not-Invented-Here (NIH) Syndrome63

“THE MAN WHO SAYS HE CAN,
AND THE MAN WHO SAYS HE CANNOTARE BOTH CORRECT”-- Confucius

64

Deploying a cybersecurity architecture
1. Assessment: Assess the organization's current security posture to identify potential risks,vulnerabilities, and areas for improvement.
2. Planning: Develop a comprehensive cybersecurity plan that aligns with the organization's goals,
priorities, and budget.
3. Design: Develop a detailed design of the cybersecurity architecture, including the different layersof security controls and how they will work together.
4. Implementation: Deploy the cybersecurity architecture, which may involve implementing new
security controls and configuring existing ones.
5. Testing: Conduct testing to ensure that the cybersecurity architecture is working as intended andthat all security controls are properly configured.
6. Maintenance: Regularly maintain and update the cybersecurity architecture to ensure that itremains effective against emerging threats and that it aligns with the organization's changing
needs and priorities.
7. Deploying a cybersecurity architecture requires a coordinated effort between IT, security teams,
and business stakeholders.

65

OWASP SAMM v2.0

The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate
and implement a strategy for software security that is tailored to the specific risks facing the organization.

REFERENCESNIST SP 800-160• https://csrc.nist.gov/publications/detail/sp/800-160/vol-1-rev-1/final• https://csrc.nist.gov/publications/detail/sp/800-160/vol-2-rev-1/finalAWS Security by Design Framework• https://aws.amazon.com/compliance/security-by-design/
SABSA Framework• https://sabsa.org/sabsa-executive-summary/
COBIT• https://www.isaca.org/resources/cobit
PCI SSF• https://www.pcisecuritystandards.org/document_library/OWASP SAAM
• https://owasp.org/2020/02/11/SAMM-v2

67

THANK YOU!

68

BIO
Miguel (Mike) O. Villegas is the President and Founder of iSecurePrivacy, LLC. His is currently CISO for
TRISTAR Insurance Group, the largest privately-owned Third-Party Administrator (TPA) in USA. He is also
current CTO for Xahive, a cybersecurity software firm specializing in security awareness training andcompliance software. He was previously SVP for K3DES, LLC., Director of Information Security at Newegg,
Inc., and Contributing Writer for SearchSecurity.com -TechTarget with over 150 articles.
He has over 35 years of Information Systems Security and IT audit experience. Mike was previously Vice
President & Technology Risk Manager for Wells Fargo Services responsible for IT Regulatory Compliance andwas also a partner at Arthur Andersen and Ernst & Young for their information systems security and IS audit
groups over a span of nine years.
Mike was president of the LA ISACA Chapter during 2010-2012 and president of the SF ISACA Chapter during
2005-2006. He was the SF Fall Conference Co-Chair from 2002–2007 and also served two years as Vice
President on the Board of Directors for ISACA International. He is a CISA, CISSP, CDPSE, CEH, CSX|F, CSX|A,
and ISO/IEC Lead Implementer. As of February 1, 2023, he has fifteen (15) years experience as a PCI QSA, PAQSA and three (3) years experience as a PCI SSF Assessor. Mike is currently Certification Chair for the ISACALA Chapter and has taught CISA review courses for over 25 years.
69