CyberSecurity Review Resources for SaaS / PaasS & Other IT Solution

This post collects some useful resources to have a proper CyberSecurity review to any SaaS, PaaS, and other IT solutions.

The security architecture review (SAR) evaluates your organization's security capabilities to ensure deployed technologies are aligned with relevant compliance requirements.

The results of the security architecture review will provide a robust report showing how your organization stands with regard to its current foundation of security infrastructure investments.

Minimum Security Standards for SaaS and PaaS from Standord Unviersity

Minimum Security Standards for IaaS

Note: https://uit.stanford.edu/guide/securitystandards/iaas

Minimum Security Standards:

Infrastructure-as-a-Service (IaaS) and Containerized Solutions

Applicability:

1. The minimum security standards found here apply to IaaS managed services — virtual servers that are designed to be ephemeral — and containerized solutions.
2. All other persistent virtual servers, regardless of infrastructure, are to be managed under the Minimum Security Standards: Servers guidelines.

Standards	What to do	Low Risk	Moderate Risk	High Risk
Platform Selection	Follow the Stanford cloud solution selection workflow found at Choosing and Purchasing a Cloud Solution.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Operational Practices	As far as possible, apply the Stanford Cloud Operational Principles and Practices.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
System Architecture	As far as possible, apply the Stanford Cloud Architecture Principles for IaaS.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Account Management	Provision new cloud accounts through University IT.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Patching and Application Lifecycle	Apply high severity security patches within seven days of release. Apply all other security patches within 90 days. Use a supported operating system and application version. Use machine images only from trusted sources. Additional Elaboration: Managed Services — For managed services like Amazon RDS or Google Cloud SQL, define a maintenance window that meets the standard. Ephemeral Servers and Containers — If using an automated system to build fully patched machine images, ensure that the patched image, or container base layer, is in use in your environment within the window of time specified in the MinSec standard.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Vulnerability Management	Based on National Vulnerability Database (NVD) ratings: Identify and remediate severity 4 and 5 CVE vulnerabilities within seven days of discovery, and severity 3 vulnerabilities within 90 days. Stanford provides and recommends the Qualys toolset (which includes the Qualys Cloud Agent), however platform specific tools such as Amazon Inspector and Google Cloud Security Scanner may be used instead. If a detection tool other than Qualys is used, ISO may request a review and audit of your tool and practices as well as periodic verification of efficacy. Additional Elaboration: Managed Services — Qualys scanning may be omitted on infrastructure provider managed services, however if the platform provides a native vulnerability detection capability, it should be implemented. Ephemeral Servers — Build machine images that contain the appropriate agent, or bootstrap the installation and configuration of the agent using the management tools specific to your implementation. Containerized Solutions — Scan image for CVEs using CLAIR, Anchore, private DockerHub scan, or similar tool.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Inventory and Asset Classification	Review and update department/MinSec Cloud inventory records quarterly. Must indicate associated risk classification and service ownership. Additional Elaboration: Ephemeral Servers — Systems designed for a lifespan no greater than 7 days (commonly those in autoscaling worker groups) should be inventoried as a single application. Managed Services — Infrastructure managed services like Amazon RDS or Google Cloud SQL should be inventoried as applications.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Firewall	Use the native tools and design patterns of your platform to ensure that only the minimum necessary network communication is permitted through virtual network devices such as VPCs, load balancers, and the like. This includes access to managed services such as hosted database platforms.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Credential and Key Management	Where possible, integrate with Stanford SSO authentication for all cloud administration consoles. Abide by Stanford’s password complexity rules. Review administrative accounts and privileges quarterly. API keys: Minimize their generation. Grant minimum necessary privileges. Rotate at least annually. Do not hardcode. Do not share credentials.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Two-Step Authentication	Enforce two-factor authentication for all interactive user and administrator logins. Stanford provided Duo two-factor authentication is recommended, but other two-factor options are acceptable.		Required for Moderate Risk Data	Required for High Risk Data
Logging and Alerting	Enable any available application logging that would assist in a forensic investigation in the event of a compromise. Seek vendor or ISO guidance as needed. Forward logs to remote logging solutions. University IT Splunk service recommended, but third party SaaS solutions are also acceptable. Additional Elaboration: Administrative Activity Logs —  Log user actions and API calls that create or modify the configuration or metadata of a resource, service or project. Data Access Logs — Log user actions and API calls that create, modify, or read High Risk data managed by a service. One example would be to enable data access logs on AWS S3 buckets containing High Risk Data.		Required for Moderate Risk Data	Required for High Risk Data
Backups	Backup application data at least weekly. Encrypt backup data in transit and at rest. Store backups in independent cloud accounts.		Required for Moderate Risk Data	Required for High Risk Data
Encryption	Enable transport layer encryption for all communications external to the private cloud environment. Use TLS 1.2 or higher. Use encryption at rest if available.		Required for Moderate Risk Data	Required for High Risk Data
Data Centers	Prefer US based data center locations.		Required for Moderate Risk Data	Required for High Risk Data
Secure Admin Workstation	Cloud administration consoles should only be accessed through a Privileged Access Workstation (PAW) or Cardinal Protect workstation when logging in with an administrative account. A PAW is required for ring0 access. Administrative accounts are defined as: Accounts with the ability to make unrestricted, potentially adverse, or system-wide changes. Accounts with the ability to override or change security control			Required for High Risk Data
Security, Privacy, and Legal Review	Follow the Data Risk Assessment process and implement recommendations prior to deployment.			Required for High Risk Data
Regulated Data Security Controls	Adhere to applicable regulations: PCI, HIPAA/HITECH, NIST 800-171, GDPR, etc. For HIPAA data, ensure that only cloud services covered under a Business Associate Agreement (BAA) are used.			Required for High Risk Data

Minimum Security Standards for IaaSFor SaaS / PaaS

Note: https://uit.stanford.edu/guide/securitystandards/saas_paas

Standards	What to do	Low Risk	Moderate Risk	High Risk
Product Selection	Follow the Stanford cloud solution selection workflow found at Choosing and Purchasing a Cloud Solution.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Pre-implementation Planning	Follow the SaaS Considerations checklist. Follow the PaaS Considerations checklist. Follow the Security When Using a Cloud Product guidelines.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Inventory and Asset Classification	Review and update department/MinSec Cloud inventory records quarterly. Must indicate associated risk classification, data volume estimates, and service ownership.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Credential and Key Management	If possible, Integrate with Stanford's SSO services, preferably SAML. Review administrative accounts and privileges quarterly. Adhere to the Stanford password complexity rules if not integrated with a Stanford SSO service. API keys: Minimize their generation. Grant minimum necessary privileges. Rotate at least annually. Do not hardcode. Do not share credentials.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Encryption	Enable transport layer encryption TLS 1.2 or higher. Use encryption of data at rest if available.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Two-Step Authentication	If user login is not able to be integrated with Stanford SSO, enable two-factor authentication if offered by the solution.		Required for Moderate Risk Data	Required for High Risk Data
Logging and Auditing	Enable any available application logging that would assist in a forensic investigation in the event of a compromise. Seek vendor or ISO guidance as needed. Contractually ensure that the provider can export logs at the request of Stanford within five days.		Required for Moderate Risk Data	Required for High Risk Data
Data Management	Contractually ensure that Stanford data are purged upon termination of the agreement with accommodations as necessary to comply with any applicable regulatory obligations.		Required for Moderate Risk Data	Required for High Risk Data
Secure Admin Workstation	Administration consoles should only be accessed through a Privileged Access Workstation (PAW) or Cardinal Protect workstation when logging in with an administrative account. A PAW is required for ring0 access. Administrative accounts are defined as: Accounts with the ability to make unrestricted, potentially adverse, or system-wide changes. Accounts with the ability to override or change security controls.			Required for High Risk Data
Security, Privacy and Legal Review	Follow the Data Risk Assessment process and implement recommendations prior to deployment.			Required for High Risk Data
Regulated Data Security Controls	Follow all regulatory data controls as applicable (HIPAA/HITECH, NIST 800-171, PCI DSS, GDPR, etc.).  For HIPAA data, ensure that only cloud services covered under a Business Associate Agreement (BAA) are used.			Required for High Risk Data

 

SaaS Checklist

A SaaS product used for the Stanford community must meet these requirements:

Business requirements:

The product provides functional support for Stanford's business.
The service provider is viable and provides support for the product.
The service provider has a process to notify the user about changes in the product (e.g., functionality, UI).

Technical/integration requirements:

The product integrates with Stanford's IAM (Identity and Access Management) and account provisioning systems.
The product has the capability for service health monitoring.
The product includes log and/or event notification (e.g., it tracks administrative access or configuration changes to deployment).
The product has testing and staging environments.
The product is scalable and fault-tolerant.

Risk management requirements:

The product supports Stanford's data security requirements.
The product complies with University policy and legal requirements.
The product supports business continuity and disaster recovery.

PaaS Checklist

When looking to acquire a PaaS product for the Stanford community, follow this checklist of required attributes. More detail can be found in the sections below.

Required attributes — a PaaS candidate solution must address these three sets of considerations:

Business considerations:

Functional support for Stanford's business
Vendor support and viability
Cost
Lifecycle and exit strategy

Technical/integration considerations:

Scalability and availability
Capability for service health monitoring
Ability to integrate with and operate with Stanford services and products
Ability to integrate with Stanford IAM (Identity and Access Management) infrastructure

Risk management considerations:

Ability to support Stanford's data security requirements
Support for business continuity and disaster recovery
Ability to notify Stanford about breaches or outages
Compliance with University policy and legal requirements

Note: Minimum Security Standards | University IT (stanford.edu)

Minimum Security Standards: Endpoints

An endpoint is defined as any laptop, desktop, or mobile device.

1. Determine the risk level by reviewing the datarisk classification examples, serverrisk classification examples, and application risk classification examples and selecting the highest applicable risk designation across all. For example, an endpoint storing Low Risk Data but utilized to access a High Risk application is designated as High Risk.
2. Follow the minimum security standards in the table below to safeguard your endpoints.

Standard	Recurring Task	What to do	Low Risk	Moderate Risk	High Risk
Patching	Recurring Task	Apply security patches within seven days of publish. BigFix is recommended. Use a supported OS version.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Whole Disk Encryption		Enable FileVault2 for Mac, BitLocker for Windows. SWDE is recommended, option to use VLRE instead. Install MDM on mobile devices.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Malware Protection		Install antivirus (Recommended: CrowdStrike or Microsoft Defender for Windows, Crowdstrike for Mac).	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Backups		Back up user data at least daily. University IT CrashPlan is recommended (option to set personal password). Encrypt backup data in transit and at rest.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Inventory	Recurring Task	Review and update NetDB records quarterly. Maximum of one node per NetDB record.	Required for Low Risk Data	Required for Moderate Risk Data	Required for High Risk Data
Configuration Management		Install BigFix and SWDE.			Required for High Risk Data
Regulated Data Security Controls		Implement PCI DSS, HIPAA, or export controls as applicable.			Required for High Risk Data

Minimum Security Standards: Servers

A server is defined as a host that provides a network accessible service.

1. Determine the risk level by reviewing the datarisk classification examples, serverrisk classification examples, and application risk classification examples and selecting the highest applicable risk designation across all. For example, a server running a Low Risk application but storing High Risk Data is designated as High Risk.
2. Follow the minimum security standards in the table below to safeguard your servers.

Standard	Recurring Task	What to do	Low Risk	Moderate Risk	High Risk
Patching	Recurring Task	Based on National Vulnerability Database (NVD) ratings, apply high severity security patches within seven days of publish and all other security patches within 90 days. Use a supported OS version.	Required for low risk servers	Required for moderate risk servers	Required for high risk servers
Vulnerability Management	Recurring Task	Perform a monthly Qualys scan. Remediate severity 4 and 5 vulnerabilities within seven days of discovery and severity 3 vulnerabilities within 90 days.	Required for low risk servers	Required for moderate risk servers	Required for high risk servers
Inventory	Recurring Task	Review and update NetDB, SUSI, and  department/MinSec inventory records quarterly. Maximum of one node per NetDB record.	Required for low risk servers	Required for moderate risk servers	Required for high risk servers
Firewall		Enable host-based firewall in default deny mode and permit the minimum necessary services.	Required for low risk servers	Required for moderate risk servers	Required for high risk servers
Credentials and Access Control	Recurring Task	Review existing accounts and privileges quarterly. Enforce password complexity. Logins with SUNet credentials via Kerberos recommended.	Required for low risk servers	Required for moderate risk servers	Required for high risk servers
Two-Step Authentication		Require Duo two-step authentication for all user and administrator logins.		Required for moderate risk servers	Required for high risk servers
Centralized Logging		Forward logs to a remote log server. University IT Splunk service recommended.		Required for moderate risk servers	Required for high risk servers
Sysadmin Training	Recurring Task	Attend at least one Stanford Information Security Academy training course annually.		Required for moderate risk servers	Required for high risk servers
Malware Protection	Recurring Task	Deploy Crowdstrike. Review alerts as they are received.		Required for moderate risk servers	Required for high risk servers
Intrusion Detection	Recurring Task	Deploy  OSSEC or Tripwire. Review alerts as they are received.		Required for moderate risk servers	Required for high risk servers
Physical Protection		Place system hardware in a data center.		Required for moderate risk servers	Required for high risk servers
Secure Admin Workstation		Access administrative accounts only through a Privileged Access Workstation (PAW) or Cardinal Protect workstation. A PAW is required for ring0 access.			Required for high risk servers
Security, Privacy, and Legal Review		Follow the Data Risk Assessment process and implement recommendations prior to deployment.			Required for high risk servers
Regulated Data Security Controls		Implement PCI DSS, HIPAA, or export controls as applicable.			Required for high risk servers

Minimum Security Standards: Applications

An application is defined as software running on a server that is remotely accessible, including mobile applications.

1. Determine the risk level by reviewing the datarisk classification examples, serverrisk classification examples, and application risk classification examples and selecting the highest applicable risk designation across all. For example, an application providing access to Low Risk Data but running on a High Risk server is designated as High Risk.
2. Follow the minimum security standards in the table below to safeguard your applications.

Standard	Recurring Task	What to do	Low Risk	Moderate Risk	High Risk
Patching	Recurring Task	Based on National Vulnerability Database (NVD) ratings, apply high severity security patches within seven days of publish and all other security patches within 90 days. Use a supported version of the application.	Required for low risk applications	Required for moderate risk applications	Required for high risk applications
Vulnerability Management	Recurring Task	Perform a monthly Qualys application scan. Remediate severity 4 and 5 vulnerabilities within seven days of discovery and severity 3 vulnerabilities within 90 days.	Required for low risk applications	Required for moderate risk applications	Required for high risk applications
Inventory	Recurring Task	Review and update department/MinSec Application inventory records quarterly. Must indicate associated risk classification and data volume estimates.	Required for low risk applications	Required for moderate risk applications	Required for high risk applications
Firewall		Permit the minimum necessary services through the network firewall.	Required for low risk applications	Required for moderate risk applications	Required for high risk applications
Credentials and Access Control	Recurring Task	Review existing accounts and privileges quarterly. Enforce password complexity. Logins with SUNet credentials via WebAuth/SAML recommended.	Required for low risk applications	Required for moderate risk applications	Required for high risk applications
Two-Step Authentication		Require Duo two-step authentication for all user and administrator logins.		Required for moderate risk applications	Required for high risk applications
Centralized Logging		Forward logs to a remote log server. University IT Splunk service recommended.		Required for moderate risk applications	Required for high risk applications
Secure Software Development		Include security as a design requirement. Review all code and correct identified security flaws prior to deployment. Use of static code analysis tools recommended.		Required for moderate risk applications	Required for high risk applications
Developer Training	Recurring Task	Attend at least one Stanford Information Security Academy training course annually.		Required for moderate risk applications	Required for high risk applications
Backups		Back up application data at least weekly. Encrypt backup data in transit and at rest.		Required for moderate risk applications	Required for high risk applications
Secure Admin Workstation		Access administrative accounts only via a Privileged Access Workstation (PAW) or Cardinal Protect workstation. A PAW is required for ring0 access.			Required for high risk applications
Security, Privacy, and Legal Review		Follow the Data Risk Assessment process and implement recommendations prior to deployment.			Required for high risk applications
Regulated Data Security Controls		Implement PCI DSS, HIPAA, FISMA, or export controls as applicable.			Required for high risk applications

SaaS Vendor Evaluation Template v0.1

T E M P L A T E
EVALUATING SaaS VENDORS
This template will help you evaluate the SaaS vendors you are interested in. First rate your vendor from 1-5 for each of the criteria listed. One is the lowest score and five is the highest. Then rate the importance of each feature to your organization. The third column provides an automatic score for each feature. Once completed, check the “final evaluation" at the bottom of this table to see the final results and compare your vendors.
	Insert SaaS Vendor 1
	Vendor Grade	Urgency	Vendor Assessment
Criteria	Rate your SaaS vendor for  the features below (from 1 to 5).	Rate the importance of each feature to your organization (from 1 to 5)	Final vendor assessment (calculated automatically)
Security
GDPR compliance			0
SOC 2 compliance			0
ISO/IEC 27001			0
PCI			0
HIPAA			0
FFIEC			0
Single Sign-On Integration			0
Multi-factor Authentication			0
Service
Uptime			0
Response time			0
Dedicated Customer Success Manager			0
Community/Forum			0
Automated monthly reporting			0
Professional Services
Support			0
Cost
License terms			0
Professional Services Fee
Pricing			0
Feature-set (listed below are exampes of features for Enterprise SaaS Management solutions)
Automated discovery process			0
Extensive SaaS vendor integrations			0
ERP integrations			0
HRIS integrations			0
Single Sign-On Integration			0
Advanced reporting dashboard			0
Contract timeline			0
Contract renewal alerts			0
Actionable monthly recommendations			0
SaaS service usage insights			0
Departmental spend and utilization overview			0
Utilization rate metering			0
Compliance tracking			0
Final evaluation	0

Standards List for Security, Cloud, Operations

Security

• ISO
• CSA (Cyber Security Alliance)
• ico.
• HIPAA
• SSAE
• PCI DSS
• GDPR
• IEC
• COBIT
• Cyber Essentials
• ISAE

Cloud

• IEEE
• ISO
• IETF
• DMTF
• ETSI
• GICTF
• OpenGridForum
• SNIA
• Open Cloud Consortium
• Cloud Standards Customer Council
• NIST
• OASIS

Operations

• ISO
• ITIL
• IFPUG
• CIF
• DMTF
• COBIT
• TOGAF 9
• MOF
• tmforum
• FitSM

A Step-by-step Guide to Conducing Security Architecture Review

Note: Ezoic Flickify AI generated scripts. 

1. Introduction: Why a Comprehensive Security Architecture Review is Necessary

In today's digital age, protecting your assets is more important than ever before. With the increasing number of cyber threats and data breaches, it is crucial to have a strong security posture in place. One way to ensure this is by conducting a comprehensive security architecture review. This process involves assessing your current security measures, identifying potential vulnerabilities and threats, developing a plan for improving security, implementing changes, and monitoring progress. By taking these steps, you can better protect your assets and maintain a strong security posture. In this article, we will guide you through each step of the process to help you conduct a successful security architecture review.

2. Assessing Your Current Security Measures

Before you can begin to improve your security measures, it's important to assess your current setup. This involves taking a close look at all of the systems and processes that make up your security architecture. 

Start by reviewing your existing security policies and procedures. Are they up-to-date and comprehensive? Do they cover all potential threats and vulnerabilities? Are they being followed consistently across your organization?

Next, evaluate your physical security measures. This includes things like access controls, surveillance cameras, and alarm systems. Are they functioning properly? Are they positioned in the most effective locations? Are there any blind spots or areas where security could be improved?

You'll also want to review your network security measures. This includes firewalls, intrusion detection systems, and antivirus software. Are they up-to-date with the latest patches and updates? Have they been configured correctly to provide maximum protection? Are there any gaps in your network security that need to be addressed?

Finally, take a look at your personnel security measures. This includes background checks, training programs, and employee awareness campaigns. Are your employees aware of their role in maintaining security? Are they following best practices for password management and data handling? Are there any areas where additional training or awareness efforts are needed?

By thoroughly assessing your current security measures, you'll be able to identify areas where improvements are needed and develop a plan for strengthening your overall security posture.

3. Identifying Potential Vulnerabilities and Threats

Once you have assessed your current security measures, the next step is to identify potential vulnerabilities and threats. This involves examining all aspects of your organization's operations, including physical security, network security, and employee behavior. 

One common vulnerability is outdated software or hardware that may no longer receive security updates. This can leave your systems open to exploitation by hackers who are constantly searching for weaknesses to exploit. Another potential threat is phishing attacks, where employees are tricked into giving away sensitive information or clicking on malicious links.

Physical security is also an important consideration. Are there any areas of your facility that are not properly secured? Are there any access points that could be exploited by unauthorized individuals? These are just a few examples of the types of vulnerabilities that should be identified during a comprehensive security architecture review.

It's important to note that identifying vulnerabilities and threats is not a one-time event. As technology and tactics evolve, new vulnerabilities will emerge. That's why it's crucial to regularly conduct security reviews and stay up-to-date on the latest threats and best practices for mitigating them.

4. Developing a Plan for Improving Security

Once you have identified potential vulnerabilities and threats in your current security measures, it's time to develop a plan for improving security. This plan should address the specific weaknesses that were identified and include actionable steps for addressing them. 

It's important to prioritize the most critical vulnerabilities and threats first, as well as consider the cost and resources required for each step of the plan. You may need to involve multiple departments or teams within your organization to ensure that all aspects of security are adequately addressed.

Your plan should also include timelines for implementing each step and clear metrics for measuring progress. This will help you stay on track and ensure that improvements are being made effectively.

It's important to note that a comprehensive security architecture review is not a one-time event. Your plan for improving security should be an ongoing process that is regularly reviewed and updated as new threats emerge or changes are made to your organization's infrastructure. By continuously monitoring and improving your security posture, you can better protect your assets and reduce the risk of a security breach.

5. Implementing Changes and Monitoring Progress

After developing a plan for improving security, it's time to implement the changes and monitor progress. This is where the rubber meets the road, and it's important to stay focused on the end goal of protecting your assets.

First, prioritize the changes that need to be made based on their potential impact and feasibility. Start with the most critical changes and work your way down the list. Make sure to involve all stakeholders in the implementation process, including IT staff, security personnel, and any third-party vendors.

Once the changes have been implemented, it's important to monitor progress and measure the effectiveness of the new security measures. This can be done through regular audits, vulnerability scans, and penetration testing. It's also important to stay up-to-date on emerging threats and adjust your security posture accordingly.

Remember that security is an ongoing process, not a one-time event. Regularly review and update your security measures to ensure that they remain effective and aligned with your organization's goals and objectives. By taking a proactive approach to security, you can protect your assets and maintain a strong security posture over the long term.

6. Conclusion: Maintaining a Strong Security Posture

In conclusion, conducting a comprehensive security architecture review is crucial for protecting your assets. By assessing your current security measures, identifying potential vulnerabilities and threats, developing a plan for improving security, implementing changes, and monitoring progress, you can maintain a strong security posture. Remember that security is an ongoing process, and it's important to regularly review and update your security measures to stay ahead of emerging threats. With a proactive approach to security, you can minimize the risk of security breaches and protect your assets from harm.

Video

References

• SaaS Vendor Criteria Matrix
• Choosing a SaaS Solution (University of Colorado)