In complex integrated environments on the cloud; security becomes the central feature not only of design; but of governance. CISO operations should be kept in house, and utilise external security domain experts (AWS certified for eg) to aid in providing best of breed security. Do not outsource security in whole, but only, and deliberately, in part. Security is so vital for cloud deployments that it has to be main feature of design. An aspect of design is simplicity and utility. As cloud platforms mature and develop into complex workflows and streams, it will become increasingly difficult to both deploy and manage complex security protocols, products and procedures. However, if we design security as the cornerstone of our cloud system, we should be able to maintain best of breed security, within a manageable and simplified (elegant, but robust), architecture. Because security is so vital, you should retain in-house control and not be wholly dependent on external parties.
The follow matrix is a table explaining the security principles around a complex cloud environment which includes the following:
- SSO via OKTA
- O365 for exchange, email
- Applications in AWS VPCs
- ServiceNow as ITSM and access portal
- API management via Mulesoft
- Perimeter security with Vider
- Privileged access management (to instances, and servers)
- End user monitoring with DTEX
Table A: Responsibility, Accountability Matrix: Security – an example
Key Security Areas | Principle | Client Responsibility | SI Responsibility | Other Vendors R/A | |
Access (end user, devops) | Zero Trust, Zero Touch for access. Access is role based and subject to authorisation, authentication and monitoring. | Set up of AD, OKTA, Network Access, Roles, Networking WAN connectivity to AMS | Usage of Roles, Access Policies, Password Policies | OKTA, AMS-AD, AMS for DNS, DTEX monitoring | |
Details in CSBP and NIST documents supporting this table | AD, DNS | Integration of on-premised AD with AMS Proxy AD
Zero Trust |
Secure WAN connections | DNS, Route 53, AD on AMS, AMS IaaS security management. DNS vector protection | |
Asset Management | Devices or access nodes to be locked down and secured, monitored
Zero Trust
|
Client to use OMS, deploy DTEK | Devices – DTEX (logging)
Devices – OMS (environment) Splunk to consolidate logging, monitoring |
||
CMDB | Configuration management database logs all changes to the virtual cloud environment immediately. | Configuration and setup | Usage, integration with the CMDB | ServiceNow | |
Data | All data must be secured in transit and at rest within the entire architecture
Zero Touch, No outside access |
Co R with SI and AMS | Encryption, AWS BSP, Data in Devops, Secured in transit, Snapshots | Malware Scanning -TrendMicro/AMS, Symantec, AMS for RDS, disk data at rest | |
DevOps
|
Data within DevOps must be masked, used securely, immune to hacking
Zero Touch, No outside access |
Access to SSH Port 22 as an exception
Masked Build Data |
Encryption of data in transit, at rest, secured S3, Secured EC2, Secured Jenkins | PAM, AMS services | |
GDPR, Data Protection, Data compliance laws | Compliance with legal statutes and protection of all data, proper reporting
Zero Trust, No outside access |
Compliance procedures including reporting | Application and Database encryption | All Vendors audited for compliance | |
Mulesoft | Mulesoft is an API management platform, which allows decoupling, API access must be locked down
Zero Trust, Zero Trust |
Mule account setup | Encryption of data | Mule and its native Security including PGP, PBE, iPaaS network and security management | |
Maintenance | Systems will be maintained to ensure proper security updates and policies are enacted
Zero Touch, Zero Trust |
Network provider to maintain connections to AMS and DCs | Applications
DevOps
|
AMS-VPC Networks
|
|
Monitoring | Monitoring of system usage is applied to all levels of the system including; API access, ITSM, OS, Hypervisor, Services Consumed
Zero Touch |
Set up of Splunk, AMS services to allow monitoring and logging | Automation of monitoring and logging, Integration with ServiceNow & Splunk | Splunk, Cloud Trail, Cloud Watch, AMS logs, ServiceNow HA | |
Network | Client WAN connected to AMS/AWS accounts
Zero Trust |
VPC setup, Peering, Network level security (Firewalls etc) | Work with Client on Network, DB access, Security Groups, ACLs | AMS – network security services, VPC peering connections | |
O365, Azure SaaS or PaaS | Connections to external Azure SaaS or PaaS, to be encrypted and monitored
Zero Trust |
VPN connections, WAN | AMS Domain servers | ||
Password policies for end users | SSO if possible across all applications. Along with this, end-users should normally follow a password regime, implemented in policy.
Zero Trust. |
Password policy to follow including number of characters, type, refresh period | AD, OKTA, AMS, retention and control of passwords, along with security against hacking, malicious intruder | ||
Perimeter of the Network/Platforms | All access into the AMS VPC, or SaaS platforms to be protected at each level
Zero Trust
|
OKTA, AD integration and setup
Architectural sign off on various protective layers |
DevOps, Data above OS | Perimeter-Vidder
Scanning – TrendMicro, Symantec, CA AMS Network
|
|
Source Code | Source code must be secured from breaches, leaks or theft
Zero Touch (tampering) |
Migration of code into Code Commit Repo | DevOPs process, Code Commit, HA and DR of same | ||
Workspaces | Virtual Workstations used in development and migration of code and applications
Zero Trust |
Setup and tools made available given in the BOM
AD integration (OKTA) |
MFA | AMS native Workspaces security eg Certificates, Virus scanning | |
Cloud Security Best Practices | Separate document which supports the above
Zero Trust, Zero Touch |
- End user machine monitoring (EUC) with OMS or Intune
- Application and server monitoring with Nagios, CloudWatch