Date: Fri, 29 Mar 2024 11:43:38 +0000 (UTC) Message-ID: <1429629219.45.1711712618560@481f83c81c84> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_44_1363702033.1711712618560" ------=_Part_44_1363702033.1711712618560 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The following requirements apply to systems (infrastructure, pla= tforms or other runtime environments) on which applications in target pr= oduction environment are executed:
Environment separation: Systems in production MUST be s= trictly separated from development and test systems:
Production and development MUST be separated using different environment= s (e.g. in cloud environments using separate accounts/subscriptions).
= li>Connections between different environments MUST not be possible.
Production data SHOULD not be used on non-production systems (exceptions= see 6. Security Tests).
Users and systems MUST be authorized separately for each environment.
Access servers SHOULD be separated instances for all enviro= nments but MUST be at least use separate realms.
System hardening: Systems (e.g. web servers, applicatio=
n servers, container platforms or
content management systems, cloud platforms or other runtime environments) =
MUST be hardened according to common best practices. This includes:
A hardened OS (e.g. using a hardened base image, see below),
Deactivation of all services, plugins and other functionality that is no= t needed, especially if they are exposed (executable from remote).
Hardened SSL/TLS stack (see 8.10 Data Security & Cryptography= )
Activated security headers according to Appendix A: Requirements for HTTP Security Header.
Removal of samples and other default content.
Execution of network services (e.g. web or application servers) with onl= y minimal privileges and isolated from other processes if possible (e.g. as= an isolated container or dedicated server instance, VM or host).
Network services bound to localhost if access only required from same sy= stem.
Network services should only be accessible from certain IPs if possible.=
Deactivation of file handlers that are not required (e.g. =E2=80=9C.php= =E2=80=9D for a Java application).
Deactivation of insecure HTTP methods (e.g. TRACE and TRACK).
Web and application servers must not disclose details on the server-side=
software
stack (e.g. version numbers). Related HTTP response headers such as =E2=80=
=9CServer
=E2=80=9D or
=E2=80=9CX-Powered-By
=E2=80=9D are to be deactivated or filter=
ed.
Docker security:
Docker images MUST only be build using trusted repositories.
Docker images MUST only use selected base images.
Docker images MUST be updating OS packages at build.=
Docker images MUST be scanned for insecure 3rd party components and inse= cure configuration.
Docker images MUST not consists of a remote shell like SSH or telnet.
Docker container MUST have a maximal lifetime after which they have to b= e rebuild with updated OS dependencies.
Securing access to backend resources:
Every process MUST only have the required permissions to resources such = as on the file system or database (least privilege principle). Example: =E2= =80=9Cno root permission on databases=E2=80=9D.
Access to backend systems MUST be authenticated and authorized in accord= ance to requirements of 8.13 Service &am= p; API Security.
Access to backend systems MUST use dedicated credentials for each system= .
Secrets MUST be securely stored and managed (see 8.11 Protection of Secrets)
Isolation of external systems:
Applications that are directly accessible from the Internet (or other un= trusted networks) MUST be deployed in an isolated network zone.
All external communication MUST be encrypted using TLS/HTTPS.
All external access to internal network zones = MUST be approved.
Outgoing communication (egress) to the Interne=
t MUST be restricted and SHOULD
be handled by proxies (e.g. HTTP proxies or SMTP proxies).<=
/p>
Incoming communication (ingress) SHOULD be han= dled by reverse proxies (e.g. API gateways, Web gateways).
A web application firewall (WAF) MAY be used h= ere, e.g. as an additional layer of protection, for virtual patching or as = an application IDS.
Administrative access MUST be as restricted as possible= :
Limited to required persons only, if possible using dedicated personal a= ccounts.
Username =E2=80=9Cadmin=E2=80=9D should not be used.
Limited to internal network zones or authorized IPs if possible.
Using a mandatory 2nd authentication factor (such as hardware tokens, au= thenticator apps, X.509 client certificates) in combination with a strong u= ser password.
All administrative access should be logged in a tamperproof way.
Immediately revoked after they are not required anymore (e.g. user chang= es organizational role).
System maintenance:
Systems MUST be kept up-to-date, especially in terms of security patches= .
Unused applications MUST be decommissioned.
Security scanning: Productive systems MUST be periodica= lly scanned for potential security problems. For instance:
Insecure configurations
Missing security patches
Validitiy and X.509 certificates
Exposed development artifacts (e.g. SVN files)
Potential malware infection
Security monitoring: For applications with assuranc= e class >=3D [HIGH] Possible security incidents MUST be continuousl= y monitored. For instance:
Potential account abuse or system compromise
Failures in security controls or tests
Use or assignment of critical security permissions
DoS (or other) attacks
Critical security findings from security scans (see above).
Incident management: A consistent incident management p= rocess (including roles, responsibilities escalation procedures) MUST be im= plemented and followed.