Security
- Niharika Gujela
Summary
The digital registry platform assumes no responsibility for organisational security topics concerning the platform instance. |
The application employs essential solutions(best practices) for high availability and resiliency. (e.g. autoscaling, high-throughput components, network access control, attack surface reduction, monitoring). Implementing advanced solutions for DDoS mitigation and protection is the responsibility of the infrastructure/platform owner. |
The registry platform employs the Open Web Application Security Project Application Security Verification Standard (OWASP ASVS) and the Open Web Application Security Project Security Assurance Maturity Model (OWASP SAMM) as the baseline for security assessment. |
The platform doesn't utilise self-developed authentication and user management functionality. It uses a single vetted authentication mechanism for user federation with the support of a few identity providers out-of-the-box. It can be extended further. |
The registry platform assumes no responsibility for managing organisational devices from a security perspective, such as WiFi access points or QR code readers. |
The registry platform assumes no responsibility for social network, media, and engineering threat management. |
The registry platform assumes no responsibility for public cloud security organisations, most likely using cloud-native instruments. |
The platform instance owners can address OSINT requirements. |
The digital registry platform does not provide any support for monetisation, including API monetisation or any other payments in workflows, etc. |
Terminology :
Terminology | ||
Term or Acronym | Meaning and Expansion | Comments and Links |
Access | A general term that describes the granting and restriction of access to resources for subjects. | To open a computer file or to use a computer system such as the internet. https://dictionary.cambridge.org/fr/dictionnaire/anglais/access |
Authentication | The validation of user credentials for the purpose of system login and basic access. | Authentication is the process of recognizing a user’s identity. https://economictimes.indiatimes.com/definition/authentication |
Authorization | The granting of privileges or rights for accessing the various resources hosted by a system, to a subject via a role or group for example. | Authorization is the process of giving someone permission to do or have something. https://searchsoftwarequality.techtarget.com/definition/authorization |
CIS | The Center for Internet Security (CIS) benchmarks are a set of best-practice cybersecurity standards for a range of IT systems and products. CIS Benchmarks provide the baseline configurations to ensure compliance with industry-agreed cybersecurity standards. | |
CSPM | Cloud Security Posture Management is a solution suite that enables administrators to keep track of the way in which both home grown and 3rd party services and applications access public cloud provider resources from a security perspective and enables vulnerabilities to be resolved. |
|
CUI | Confidential Unclassified Information as defined by NIST 800-171 Rev 2 |
|
CVE | Common Vulnerabilities and Exposures - a known vulnerability in a system or network component which can be exploited by a malicious attacker to gain access or create havoc. |
|
DevOps and DevSecOps | A set of principles and practices used along with tools that fully integrates and expedites the process of building, securing and deploying code on a scheduled and/or demand basis with the goals of reduced errors, reduced time-to-market, increased security and increased accuracy among others. |
|
DLP | Data Leakage Prevention - a solution typically used to prevent confidential or private information from leaking outside the organization to unauthorized 3rd parties. |
|
Federation | Federated security allows for clean separation between the service a client is accessing and the associated authentication and authorization procedures. Federated security also enables collaboration across multiple systems, networks, and organizations in different trust realms. |
|
GLBA | The Gramm-Leach-Bliley Act (GLB Act or GLBA) is also known as the Financial Modernization Act of 1999. It is a United States federal law that requires financial institutions to explain how they share and protect their customers' private information. It is also a generally accepted global standard. |
|
HIPAA | Established United States federal standard to protect individuals' medical records and other personal health information and applies to health plans, health care clearinghouses, and those health care providers that conduct certain health care transactions electronically. It is a generally accepted standard globally. |
|
IAM | Identity and Access Management - typically refers to a security suite that implements the infrastructure required for Authentication and Authorization plus the management of identities, roles, groups and access. |
|
IMAP | Internet Message Access Protocol is a mail client. protocol used for retrieval of email messages from a mail server. For the purposes of this document IMAP refers to IMAP4 which is defined by the IETF with multiple RFCs. |
|
OAuth2 | An open standards based protocol used for Authentication that uses bearer tokens and is specifically designed to work across HTTP. OAuth provides clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without providing credentials. OAuth2 is the second major release of OAuth which has been hardened based on known attacks such as “AS MixUp”. Not all implementations of OAuth2 are equal and some have been found to have security flaws. |
|
OpenIDConnect | A simple open standards based identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of a party based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the party in an interoperable and REST-like manner |
|
OWASP | The Open Web Application Security Project is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security. |
|
PaaS | Platform As A Service: A suite of software components that is fully integrated to provide a secure, convenient and rapid application development and deployment platform for cloud style applications. |
|
PCI DSS | A set of standards used by the payment card industry to secure payment card data and card holder information including primary account numbers (PAN), credit/debit card numbers, and sensitive authentication data (SAD) such as CVVs and PINs. |
|
POP | Post Office Protocol - a standard email protocol used by clients to access email once delivered to a mail server in a specific DNS domain. Various versions of this protocol exist but for the purposes of this document POP refers to POP3 as defined by RFC1939 and the extension mechanism in RFC2449 and an authentication mechanism defined in RFC1734 |
|
Provisioning | A way of propagating the joining or leaving of users from the system and creating/removing the accounts and access rights for users based on their target profile/role. |
|
Realm | A realm is a security policy domain defined for a web or application server. A realm contains a collection of users, who may or may not be assigned to a group. An application will often prompt for a username and password before allowing access to a protected resource. Access for realms can be federated. |
|
SAML | Security Assertion Markup Language. SAML and SAML2 are XML markup protocols (a suite of XMLSchema message types) designed for federation of identities across identity providers and service providers. Its main use case is for web single-sign-on. |
|
SCEP | Simple Certificate Enrolment Protocol used to enroll users and issue digital certificates. Typically supported by the certificate authority server. |
|
Single Sign On (SSO) | A way of ensuring that users only need to enter credentials once in order to gain policy access to resources across security realms. |
|
SMTP | Simple Mail Transfer Protocol - a protocol used to route email between gateways to the server responsible for final delivery to a specific DNS mail domain. |
|
Subject | In a security context, a subject is any entity that requests access to an object. These are generic terms used to denote the thing requesting access and the thing the request is made against. When you log onto an application you are the subject and the application is the object |
|
XACML | eXtensible Access Control Markup Language The XACML standard defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies all in XMLSchema. |
|
Security Management
Name |
| Description | Comments |
| FitGap comments |
Security Issues by NIST Function |
|
|
|
|
|
4.2.1 IDENTIFY |
|
|
|
|
|
4.2.1.1 Authentication and Authorization | Organizational Risk Rating: High | Authentication and Authorization MUST be addressed across the board. It is likely to be built-in to API Management and Gateway and accessed by mobile and web applications using a token based approach. All communications from all clients (web/mobile/BB clients etc.) MUST be via API so this is a sensible point of implementation given the stateless nature of applications. Authentication and authorization MUST also be addressed at an application access level for each and every application (web/mobile/desktop etc). It would be wise to utilize the same framework and capabilities for this. | Each building block MUST implement centralized authentication and authorization (minimally proxied or implemented via the common IAM solution and/or API Management and Gateway services). | Implemented | All API communications happen via API Gateway. Solution is based on Kong and Keycloak usage |
4.2.1.2 Multi-Factor Token and Password Strength/Complexity Management | Organizational Risk Rating: High | Credential strength management is likely built-in to API Management and Gateway. All communications from all clients (web/mobile etc.) must be via API so this is a sensible point of implementation also. Each application MUST provide the ability to determine credential strength at the time of registration and thus permit or deny the offered credential. | Each building block MUST implement Multi-Factor Token and Password Strength/Complexity Management for an indeterminate array of factors including biometric (this is to be implemented through leveraging a common IAM solution). | Could be implemented | Not implemented for now |
4.2.1.3 Access Control (RBAC, MAC, DAC) | Organizational Risk Rating: High | Access control is also likely built-in to API Management and Gateway. All communications from all clients (web/mobile etc.) must be via API. The thin client nature of web and mobile dictates that all resources will exist behind API interfaces so this is the most sensible point to address it (i.e. either they have access to the API or they do not). | Each building block MUST implement role based access control for all exposed API’s and resources (minimally proxied or implemented via the API Management and Gateway services) | Implemented | Each component uses role-based authorised access rules. RBAC separation of access rules also possible in DataFactory component. |
4.2.1.4 Provisioning, Deprovisioning and Management of Identities and access rights | Organizational Risk Rating: High | Will need a process based solution for this. This selection will largely depend on the identity management and API management infrastructure chosen but will likely need to be a customized process that integrates provisioning across a number of products and services. | Each building block MUST implement the ability to provision, deprovision and manage Identities and access rights (this may or may not be centralized for the whole architecture as a unified provisioning process). | Not the same approach | Registry regulation publication pipeline responsible for roles provisioning |
4.2.1.5 Access and Authorization Audit, Logging, Tracing, Tracking | Organizational Risk Rating: High | Likely built-in to API Management and Gateway. All communications from all clients (web/mobile etc. must be via API) | Each building block MUST implement access and authorization audit, logging, tracing and tracking with alerts (minimally proxied or implemented through the API Management and Gateway services). | Implemented | Platform components are sending required data (logs, tracking information) to kibana and Prometheus. |
4.2.1.6 End User Device Registration, Deregistration, Re Registration and Device Platform Security | Organizational Risk Rating: High | Significant functionality provided by MOSIP - TBD | Each building block dealing with physical devices MUST implement end user device registration, deregistration, re-registration and device platform security guidance/requirements to end users. | Not applicable | We do not have end user devices on a platform |
4.2.1.7 Biometric Security Credentials, Devices, Registration, Deregistration, Validation and device platform security | Organizational Risk Rating: High | Significant functionality provided by MOSIP - TBD | Each building block dealing with biometric credentials MUST implement biometric security credential management, registration, deregistrations, re-registration, validation and device platform security etc. such as above for biometric capture devices. | Not applicable | We do not have end user devices on a platform |
4.2.1.8 Non-repudiation and Certificates (X509, OpenID and SAML etc.) | Organizational Risk Rating: High | Likely built-in to API Management and Gateway but may also require certificate server etc. All communications from all clients (web/mobile etc. must be via API) | Each building block MUST implement a framework for non-repudiable transactions using certificates and federation protocols (X509, OpenID and SAML 2.0 etc.) | Could be implemented | Certificates verification planned to be implemented |
4.2.1.9 Single-Sign-On and 3rd Party Security | Organizational Risk Rating: High | Likely built-in to API Management and Gateway. All communications from all clients (web/mobile etc. must be via API) | Each building block MUST be able to implement single-sign-on integration with 3rd party security. | Implemented | Each client-facing BB able to do this. |
4.2.2 PROTECT |
|
|
|
|
|
4.2.2.1 Authentication and Authorization | Organizational Risk Rating: High | Applies to all connections throughout all components such as: | Each building block MUST implement SSL and TLS based connections for all TCP connectivity both external to the building block, and internally between components in a selective manner depending on data requirements. | Implemented | Communication with client facing BB happens using secure connections (HTTPS) |
4.2.2.2 Data Sovereignty/Residency Controls and Hosting, Transmission, Backup and Recovery | Organizational Risk Rating: Medium | Probably needs to be addressed during country rollouts due to data sovereignty regulations but needs to be catered for in the architecture options. | Each building block where dealing with citizens data MUST provide the ability to implement data sovereignty/residency controls, hosting, transmission, backup and recovery in compliance with specific national laws and guidelines in each country. | Implemented | Data residency could be controlled by a data-holding component deployment location (like DataFactory + Relational DB). |
4.2.2.3 Network Security, Protocols and Firewall implementations | Organizational Risk Rating: High | Infrastructure oriented but could be addressed at least in part by software defined networking (SDN) which can be part of a modern PaaS such as OKD | Each building block shall comply with the overall secure networking architecture that will be deployed in place with each country implementation. Issues such as network security, networking protocols and firewall implementations etc. shall be defined as a part of the recommended architecture showing the various zones and separations required. | Implemented | OKD |
4.2.2.4 Application Services Security (multi-tenancy etc.) | Organizational Risk Rating: High | Likely best implemented as a feature of the chosen PaaS framework such as OKD | The components for each building block are required to be deployed in containers according to the architecture description. The chosen container orchestration platform and PaaS solution shall provide the means to implement Application Services Security (such as multi-tenancy etc.) | Implemented | All of the components are deployed in separate containers. Isolation on a network policies level is in place. |
4.2.2.5 VPN and Secure Network Access Controls | Organizational Risk Rating: High | Infrastructure oriented but could be addressed at least in part by software defined networking (SDN) which can be part of a modern PaaS such as OKD | Each building block MUST comply with a defined set of VPN and Secure Network Access Controls. This will be based on the location of event producers and consumers on the network and hope the various segments of networking are sliced and protected. These standards are to be defined as a part of the target architecture implementation for each country. | Implemented | No VPN's. Platform owner responsible for setup VPN solution. Secure Network Access control in place. |
4.2.2.6 Network Vulnerability Scanning | Organizational Risk Rating: Medium | Can be sourced from open source tooling such as OpenVAS, Wireshark etc. | A suite of open source tools are to be adopted for the purposes of Network Vulnerability Scanning. These tools MUST be acquired by the project and centrally deployed in each country to ensure adequate network service security is in place. | Not applicable | We are not providing tools for network scanning. This is the responsibility of a customer who is owning the platform instance. |
4.2.2.7 Software Defined Networking and Network Slicing | Organizational Risk Rating: Medium | Infrastructure oriented but could be addressed at least in part by software defined networking (SDN) which can be part of a modern PaaS like OKD | The project MUST adopt a software defined networking solution as a part of the core deployment architecture. This can and SHOULD be implemented as a part of the chosen PaaS solution. | Implemented | OKD |
4.2.2.8 Operating Systems, Services Security and Immutability | Organizational Risk Rating: High | Infrastructure oriented but could be addressed at least in part by OS like Centos which can be part of a modern PaaS such as OKD | The project MUST deploy all services (typically microservices) on an immutable operating system infrastructure. Typically this can and SHOULD be provided as part and parcel of the chosen PaaS solution. The reason for this is such that if a security breach does happen then the operating system running the component cannot be modified by the offender. | Implemented | OKD |
4.2.2.9 Network, Service and Transaction Observability and Visibility | Organizational Risk Rating: Medium | Can be addressed as part and parcel of a modern PaaS solution such as OKD including a service mesh such as ISTIO | The project MUST implement a PaaS infrastructure that supports Network, Service and Transaction Observability and Visibility for protection against flaws and faults. This is so that complex transactions involving multiple components (likely microservices) can be observed and traced for the purposes of debugging and auditing. This would typically be implemented at least in part by a service mesh feature of the PaaS along with other integrated components for visualization such as the Jaeger open source tracing facility and the Kiali open source visualizer for example. | Implemented | OKD, Kiali, Jaeger |
4.2.2.10 Man-in-the-middle (MITM) Attack Prevention (AKA Session Hijack) | Organizational Risk Rating: Medium | Needs to handle insecure WIFI, email spam filtering, virus scanning and ad-blockers etc. at all levels. | Needs to handle insecure WIFI, email spam filtering, virus scanning and ad-blockers etc. at all levels. | Not the same approach | Wifi, email's - is not a part of platform's responsibility |
4.2.2.11 Cloud Platform Configuration Management and Securing Configurations | Organizational Risk Rating: High | Can be addressed as part and parcel of a modern PaaS solution such as OKD (which has secure encrypted stores for credentials) | Each building block MUST adopt the facilities of the chosen PaaS for implementing Cloud Platform Configuration Management and Securing Configurations. For example authentication credentials for common components like databases need to be managed appropriately and simply across multiple environments through DevOps automated deployment etc. | Implemented | Storage for credentials - HashiCorp Vault |
4.2.2.12 Insider threats and internal audit-ability | Organizational Risk Rating: Medium | The same security protocols, data encryption, protections and monitoring to be applied consistently both internally and externally. | Each building block MUST adopt the same consistent security and privacy implementation measures to protect against Insider threats and internal audit-ability as those adopted for external exposures. This is a general statement. | Could be implemented | Insider threats are not in the scope of security protection for a moment |
4.2.2.13 Denial of service attack prevention | Organizational Risk Rating: Medium | Can be managed by implementing open source tools/services such as CrowdSec and DDOS Deflate, Fail2Ban, HAProxy, DDOSMon, NGINX etc. Note that HAProxy is built into PaaS solutions like OKD - TBD. Note that a number of API Gateway products are built around NGINX | The project must implement an open source Denial of service attack prevention solution across all interfaces exposed to the public internet for each country deployment. This can be implemented through a reverse proxy web server environment using open source tools such as Fail2Ban, DDOS Deflate or HAProxy. | Not applicable | Responsibility of platform instance owner |
4.2.2.14 API Endpoint Security Policy Management and Gateway Services (both internal and external) | Organizational Risk Rating: High | The implementation of a centralized API Management and Gateway solution is probably not negotiable. All API interfaces both internal and external must be managed through this facility. Architecture will likely require a separate gateway for both internal and external services. | The project MUST implement centralized API Endpoint Security Policy Management and Gateway Services (both internal and external). The reason for this is to implement a consistent layer of security for API interfaces that can be both managed centrally and alleviate the service developers from the implementation complexity of security. This can and SHOULD be implemented through an open source API Management and Gateway services product. | Implemented |
|
4.2.2.15 Virus/Malware and Ransomware Attack Prevention and Detection | Organizational Risk Rating: High | Requires extensive and probably commercial software in many layers. | The project MUST implement protection from and detection of Virus/Malware and Ransomware Attack. This likely requires a commercial solution suite as open source offerings are insufficient and not suitable for massive country-wide deployments w=such as GovStack. | Could be implemented | Not implemented for a moment |
4.2.2.16 Credential Theft Prevention | Organizational Risk Rating: High | Can be addressed as part and parcel of a modern PaaS solution such as OKD (which has secure encrypted stores for credentials). Requires implementation through all development procedures and CI/CD etc. | The project MUST implement credential theft prevention as part and parcel of its selected PaaS infrastructure. This is essentially an encrypted keystore that can host sensitive credentials and provide access to them with policy based security. | Implemented | HashiCorp vault is used |
4.2.2.17 SQL Injection Attack Prevention | Organizational Risk Rating: High | Can be addressed through open source tools such as those provided by the OWASP Foundation. Plugins for OWASP tools are available for PaaS solutions like OKD | The project MUST implement SQL Injection Attack prevention as part and parcel of any and all applications development across building blocks. This can be implemented through open source tools such as those provided by the OWASP Foundation. This can and SHOULD be implemented as plugins through the PaaS solution and fully integrated into the DevOps toolchains for the project build and deployment. | Implemented | OWASP scanner used in a build pipeline for an artefacts |
4.2.2.18 Containing, Managing and Mitigating Hardware/Firmware Vulnerabilities and Known Exploits (directory traversal, rowhammer, spectre, meltdown, LazyFP etc.) | Organizational Risk Rating: High | Typically these types of attacks are best mitigated by the use of commercial open source subscriptions as they close the window of vulnerability. New CVE’s happen every month and are becoming more common as IT advances. The upstream open source projects like OKD will eventually get the patches but it will be some time after commercial open source product patches are released to those with enterprise subscriptions. | The project MUST implement solutions for Containing, Managing and Mitigating Hardware/Firmware Vulnerabilities and Known Exploits (directory traversal, rowhammer, spectre, meltdown, LazyFP etc.). This can and SHOULD be implemented through plugins to the PaaS solution and DevOps toolchain for the project to ensure that every single component deployed is scanned for known CVEs. | Not applicable | The platform is not responsible for the hardware it is running on. The owners of a platform instance should organise such scanning for vulnerability. |
4.2.2.19 Data Privacy/Loss/Leakage/Confidentiality (individuals and organisations) | Organizational Risk Rating: High | For the most part this involves end-point protection. Some tools are available in open source but it requires multiple layers of implementation and is thus more expensive. | The project SHOULD implement solutions for prevention against Data Privacy/Loss/Leakage/Confidentiality (individuals and organisations). This likely requires expensive commercial packages rather than open source tooling. | Could be implemented | Private data functionality planned to be implemented |
4.2.2.20 Data Security (at rest and in transit - i.e. encryption and obfuscation etc.) | Organizational Risk Rating: High | Needs to be considered for each data store and each connection in the architecture. It is a very broad topic that must be addressed in the context of the data confidentiality requirements for each country implementation. Will be relatively expensive for resource-limited settings but it is a necessity. | The project MUST implement solutions for Data Security (at rest and in transit - i.e. encryption and obfuscation etc.) consistently across all datastores and connections within and surrounding all building blocks. | Could be implemented | Not all data storage is encrypted momentarily, which could be improved. |
4.2.2.21 Cross-site Scripting (XSS) Attack Prevention | Organizational Risk Rating: Medium | By virtue of the fact that each BB will host its own UI there is strong potential for cross-site scripting vulnerabilities. Rules must be adhered to by developers. For example, all DOM based XSS reflection or embedding must be performed on the server side not in the ECMA layer. Several other rules must also be implemented for developers to reduce the likelihood of XSS vulnerabilities. Many of these rules can be found here on the OWASP web site: | The project must provide a consistent set of rules for cross site scripting across all building blocks to ensure that it is not exposed to Cross-site Scripting (XSS) Attacks. This is a complex area that must be addressed during development and testing. Details of many of the rules that must be implemented can be found on the OWASP web site. | Implemented | SAST, DAST, data input requirments |
4.2.2.22 Replication and Perimeter/Edge Data and Services Security | Organizational Risk Rating: High | This is complex and applies to large architectures with multiple data centers and perimeter services. Every single element of the networks and trusts must be examined for vulnerabilities. There is no simple one-shot solution for this as it involves multiple data centers and multiple layers communicating and replicating potentially sensitive data. The degree to which this is addressed is commensurate with the relative sensitivity of the data and services involved. | The project MUST provide Replication and Perimeter/Edge Data and Services Security. This assumes that practically all national deployments will have multiple sites that must be protected from breaches and leakages as a result of technology services deployed to distribute and consolidate data. | Not applicable | Platform responsible for protecting data within OKD cluster. |
4.2.2.23 Social Media, Social Network and Social Engineering Threats and Prevention | Organizational Risk Rating: High | This is a complex subject that requires not only technical intervention but extensive training for everyone involved in the processes of eGovernment. | The project MUST provide protection from Social Media, Social Network and Social Engineering Threats. This is not only a technology services issue but also applies to standard operating procedures and requires extensive user education. | Not applicable | Trainings could be implemented by a customer |
4.2.2.24 Centralized PAAS Management, Monitoring and OTA Automated Update | Organizational Risk Rating: Medium | Can be addressed as part and parcel of a modern PaaS solution such as OKD - TBD (which has over the air update capabilities along with centralized management and monitoring). | The project MUST provide Centralized PAAS Management, Monitoring and OTA (over-the-air) Automated Update for infrastructure and applications components. This is to ensure that patches to emerging and common vulnerabilities are addressed in the smallest window possible and the whole architecture is not exposed through such vulnerabilities. This can and SHOULD be addressed as part and parcel of the selected PaaS infrastructure. | Could be implemented | no automatic updates |
4.2.2.25 Digital Service Registry Security | Organizational Risk Rating: High | Can be addressed as part and parcel of a modern PaaS solution such as OKD - TBD (which has an embedded services registry) - there may be other registries required that are also impacted. There needs to be careful delineation of functionality and terminology used for registries as there are many implications in PaaS environments such as for service exposure through software defined networks etc. | The project and all building blocks utilizing registries of any kind (particularly digital service registries) MUST provide Digital Service Registry Security. This means ensuring that the protocols, interfaces and connections to such centralized services are controlled in accordance with the other requirements for connections and API etc. | Implemented | OKD internal service |
4.2.2.26 Surrounding Networking Software Infrastructure Security (DNS, DHCP , PXE, BootP services etc.) | Organizational Risk Rating: High | Each core network service must be addressed in its own right. There is too much to discuss here but these services are critical, exposed, prone to vulnerabilities and must be secured with the highest possible standards applied. | The project MUST address the general Surrounding Networking Software Infrastructure Security (DNS, DHCP , PXE, BootP services etc.) for each and every country rollout. These services are particularly vulnerable as some of them are exposed to insecure zones (especially DNS). | Implemented | Surrounding network software infrastructure is the responsibility of OKD, not a platform. So updates for those services will be applied during the OKD instance update. |
4.2.2.27 Cloud Provider Infrastructure Security (hardware layer, infrastructure layer, virtualisation, container and platform layer, application layer) | Organizational Risk Rating: High | Each cloud service must be addressed in its own right. There is too much to discuss here but these services are critical, exposed, prone to vulnerabilities and must be secured with the highest possible standards applied. | The project MUST provide protection against common vulnerabilities in Cloud Provider Infrastructure Security (hardware layer, infrastructure layer, virtualisation, container and platform layer, application layer etc.). This is specific to each public cloud provider where utilized but a common source of threats since they involve complex suites of services that are stitched together (most often by the implementer not the cloud provider) in multiple layers to form the solution architecture. | Not the same approach | Platform instance owners responsible for Cloud Provider infrastructure security |
4.2.2.28 Mobile and Wireless Networking Security/WIPS | Organizational Risk Rating: High | Mobile and wireless networking security is a significant issue to deal with given that there will likely be mobile applications deployed as a part of the architecture. A plethora of issues abound including for example Evil Twin Attack, WarDriving (piggyback attack), sniffing and shoulder-surfing etc.. CISA has released a short guide here for securing wireless in general: | The project MUST provide protection against Mobile and Wireless Networking Security/WIPS vulnerabilities. There are many potential and known vulnerabilities around these networks which have predicated information security in the digital age. The potential for eavesdropping and information leakage as well as other forms of hijacking attacks is very broad as the exposure is over-the-air. | Not applicable | Mobile devices and Wireless networks are not a part of platform responsibility |
4.2.2.29 Compressed and Encrypted Information Transmission via Messaging and Email etc. to external or internal 3rd parties along with any other potential forms of critical information leakage. | Organizational Risk Rating: High | This is principally the same as endpoint security to prevent information leakage. | The project (including all building blocks MUST provide protection against private information leakage through Compressed and Encrypted Information Transmission via Messaging and Email etc. to external or internal 3rd parties along with any other potential channels for critical private information leakage. | Could be implemented | No personal data implementation for a moment |
4.2.2.30 Anti-Phishing and Anti-Spam | Organizational Risk Rating: High | Phishing and the associated spam are two of the most common digital platform security problems and must be dealt with. A number of open source solutions exist such as OrangeAssassin, MailScanner and Apache SpamAssassin. These are commonly used by many commercial sites all around the world. | The project MUST provide Anti-Phishing and Anti-Spam tooling. These are some of the most common sources of security issues and can be dealt with using open source tools such as Orange Assassin, MailScanner and SpamAssassin. | Not applicable | We have no client mailboxes managed by a platform, so we can't receive any mail messages with phishing or spam. |
4.2.2.31 Physical Security and Access Controls to Facilities | Organizational Risk Rating: High | Physical security is a must for all on-premise facilities and almost goes without saying. The extent to which physical security is implemented must comply with national government hosting standards in each country. | The project MUST provide physical security measures for access to physical facilities. | Not applicable | responsibility of platform instance owners |
4.2.2.32 Portable and Removable Media Controls | Organizational Risk Rating: High | This is commonly known as endpoint security and must be dealt with comprehensively either at hardware level (by disconnection) or in software that allows policy and procedure for removable media to be controlled. | The project MUST provide portable and removable media controls to protect against information leakage. | Not applicable | responsibility of platform instance owners |
4.2.2.33 Backup Security and Backup Information Controls | Organizational Risk Rating: High | This is a complex and diverse area to address as there will be several data repositories and databases in the deployed infrastructure including both CUI and regular non-CUI information. Backups are one of the areas that create large exposure for information loss and must be addressed consistently and thoroughly. | The project must provide backup information controls and security to prevent information leakage and tampering etc. through the backup and recovery processes. This applies to all building blocks. | Could be implemented | Backups are not encrypted now |
4.2.3 DETECT |
|
|
|
|
|
4.2.3.1 Vulnerability Management and Security Automation | Organizational Risk Rating: Medium | Several open source and commercial tools are available to address this in terms of scanning for vulnerabilities in all layers of the solution including containers for example. The process and tools for this need to be addressed specifically depending on the technical components of the final solution architecture. | The project MUST provide tools to detect, manage and automate the resolution of common vulnerabilities in all layers (applications components down to infrastructure components) before they eventuate as deployed in the solution. There are many open source scanning tool options available for this purpose. CISA defines the standards for this and refers to many of the available open source tools. | Implemented | Defect Dojo |
4.2.3.2 Applications Development, Deployment, DevSecOps and Container Image Security | Organizational Risk Rating: Medium | This needs to be built-in to the CI/CD process to ensure that only secured images are deployed to production. Most modern PaaS offerings such as OKD - TBD are also shipped with a rudimentary suite of tools to accomplish this. | The project MUST provide a secure DevSecOps process for code deployment. This applies to areas surrounding Applications Development, Deployment, DevSecOps and Container Image Security scanning (i.e. what's inside the container) before applications components are deployed. | Implemented | Trivy, dependency-track, kics |
4.2.3.3 Compliance Checking and Scanning (PCIDSS/HIPAA, CIS etc.) | Organizational Risk Rating: Medium | These are global standards for security compliance checking and several tools are available in the market to address this. Both commercial and open source options are available. | The project MUST provide tooling support for Compliance Checking and Scanning (PCIDSS/HIPAA, CIS etc.). A number of open source tools and commercial off-the-shelf tools are available for this purpose. This compliance checking MUST be conducted on a regular basis for all building blocks dealing with financial, healthcare and personal data in accordance with the aforementioned PCIDSS, HIPAA and CIS standards. | Implemented | OWASP ASVS, OWASP SAMM |
4.2.3.4 Security Risk Profiling | Organizational Risk Rating: Low | Several tools are available in this space with varied ways of addressing the concerns including threat modeling | The project SHOULD provide tools for Security Risk Profiling. Several such tools are available and offer assessment of security risks through techniques such as threat modeling. | Could be implemented |
|
4.2.3.5 Threat/Intrusion Detection and Prevention | Organizational Risk Rating: High | Several open source tools are available to address this space admirably including for example Snort, Bro, Kismet, OSSEC and Open DLP etc. These are VERY effective, VERY mature and easily adopted. | The project MUST deploy tooling for Threat/Intrusion Detection and Prevention in the infrastructure and other layers. Several such tools are available in open source (Snort, Bro, Kismet, OSSEC etc.) | Could be implemented | We can add IDS and IPS container runtime solutions to a platform |
4.2.3.6 Login Notifications and Alerts etc. (new device or IP etc.) | Organizational Risk Rating: Medium | This should be managed with the basic user device profile and an alert sent via email and other channels whenever a login is made from a new endpoint, giving the user the option to lock the account. | The project across all building blocks SHOULD provide Login Notifications and Alerts etc. (new device or IP etc.) where email or other notifications would be sent to recipients with warning messages when authentication is performed from a new device. This also involves keeping a registry of registered devices for each user/party/actor (albeit internal or external and the ability for them to lock their account if the authentication was achieved by an unknown party. | Could be implemented | No login related alerts implemented |
4.2.3.7 Open Source Intelligence (OSINT) Platforms/Tools and Processes | Organizational Risk Rating: Low | OSINT gathering is COMPLEX. The following article describes the origins and tools of OSINT that have evolved from the original Metasploit (white hacking solution): | The project SHOULD provide Open Source Intelligence (OSINT) Platforms/Tools and Processes in order to perform security assessments on open source usage. This essentially incorporates the hackers tools into the protection and detection arsenal (see the evolution of Metasploit and other white hacker solutions in open source). | Not the same approach | We do not utilise the OSINT approach during a security assessment |
4.2.3.8 Information gathering and Security Data Visualization | Organizational Risk Rating: Low | This is an emerging area of value that largely comprises of the following types of visualizations but there are no comprehensive open source tools available: | The project SHOULD provide tooling for Information gathering and Security Data Visualization for maintaining security observability through operations. Many different visualizations are available through various commercial tools but no comprehensive open source solution is available. | Could be implemented | No data visualisation for a moment. Not all of the areas is the responsibility of the digital platform. |
4.2.3.9 Fraud Detection and Management | Organizational Risk Rating: High | Fraud detection and management is the set of activities carried out to check money or property from being acquired through false pretenses is known as fraud detection and the ability to trace and manage incidences of fraud. In many industries like banking or insurance, fraud detection is applied. SInce this project involves money exchange there is a case for fraud detection and management. Number of open source tools including the following are available: FraudLabs Pro, , MISP, pipl, Sift etc.. See this article for a deeper description: https://www.goodfirms.co/blog/best-free-open-source-fraud-detection-software | The project MUST provide tooling for Fraud Detection and Management. This is not negotiable and many open source tool sets currently exist such as FraudLabs, and MISP. This applies to all building blocks dealing with financial transactions and information (such as payments - which appears to be bidirectional… i.e. govt-to-recipient and payee-to-govt). | Not applicable | No payments functionality on a platform for a moment |
4.2.4 RESPOND |
|
|
|
|
|
4.2.4.1 Incident Response and Management - applies to attempted and successful intrusion, fraud, hacking, phishing incidents and all other forms of security incident | Organizational Risk Rating: High | Incident Response and Management (ticketing etc.) - applies to attempted and successful intrusion, fraud, hacking, phishing incidents and all other forms of security incident | The project MUST provide Incident Response and Management (ticketing etc.) - This applies to both attempted and successful intrusion, fraud, hacking, phishing incidents and all other forms of security incident. This applies across all building blocks and must be built-in to the infrastructure and processes of each building block when any incident is detected. | Could be implemented | No Incident Response and Management automated process in place |
4.2.4.2 Security Sandbox Solution - used to test responses to potential/predicted security incidents | Organizational Risk Rating: Low | This would involve creating a sandbox environment to test and resolve security issues thus requiring a complete sandbox of all the security tools mentioned here. | The project MUST provide a Security Sandbox Solution - used to test responses to potential/predicted and actual security incidents. | Could be implemented | Partially implemented |
4.2.5 RECOVER |
|
|
|
|
|
4.2.5.1 Critical digital infrastructure business continuity considerations (terrorism, sabotage, information warfare, natural disasters etc.) - processes and how to recover digital infrastructure. | Organizational Risk Rating: High | This is more of a planning and execution exercise and simply must be built-in to the overall deployment game plan for every single piece of software infrastructure and data infrastructure along with the processes and procedures as well as test recoveries to ensure that an adequate recovery response can be attained on demand. | The project MUST deal with Critical digital infrastructure business continuity considerations (terrorism, sabotage, information warfare, natural disasters etc.) - i.e. provide the technical ability and processes required in order to recover the complete digital infrastructure. This applies to all building blocks and must also endure recovery testing on a regular basis. | Not applicable | The platform backup/recovery process covers only the application layer. Backup/restore for other layers, like infrastructure, should be managed by an owner of the specific platform instance. |
4.2.5.2 Specifically Security Related Concerns surrounding BIA/DRP/BCP (disaster recovery, business continuity etc.) - how to recover to specific data versions using logging tracking and tracing information to determine the best path. | Organizational Risk Rating: High | This is similar or the same as the concern above and simply elaborates it further. | The project MUST deal with Specifically Security Related Concerns surrounding BIA/DRP/BCP (disaster recovery, business continuity etc.) - what this means is how to recover to specific data versions using logging, tracking and tracing information to determine the best recovery path. This also covers the security of the backups themselves to prevent fraud, tampering and information leakage during storage or recovery for example and MUST address the exact data security requirements stipulated throughout this document but in the context of backups. | Not applicable |
|
4.2.5.3 Cloud Security Posture Management (automation of identification and remediation of risks with public cloud services) | Organizational Risk Rating: High | This is a more advanced and aggregated way of determining the overall security posture in respect to public cloud based deployments and takes into account all of the risks. There are a number of open source solutions available such as OpenCSPM (cloud security posture management). Really only applicable with deployments on public clouds but becoming essential. | The project SHOULD implement Cloud Security Posture Management (automation of identification and remediation of risks with public cloud services). Open source tools such as OpenCSPM are available. | Could be implemented |
|
4.2.5.4 Digital Service Registry State Recovery | Organizational Risk Rating: High | It seems the concept of registry is morphing into something more generic than it was originally (which seemed to be a service registry). The state recovery for this is contingent on the technology solution that the Registration BB takes. Losing the state of this registry due to a security issue is a key risk that MUST be mitigated. | The project MUST provide the ability for specific Digital Service Registry State Recovery (point-in-time). Registries are one of the most likely early targets of cyber-criminals. This applies predominantly to the Registry building block. | Not the same approach | No point in time recovery. The periodical backup approach was used instead. |
4.2.5.5 Controlled Unclassified Information (CUI) Registries, Repositories and Processes (i.e. marking, safeguarding, transporting, disseminating, reusing and disposing of controlled unclassified information) | Organizational Risk Rating: High | This is all about how information is controlled throughout systems based on its secrecy/privacy classification. | This is a bit more general but the project SHOULD provide the ability to manage and recover Controlled Unclassified Information (CUI) Registries, Repositories and Processes (i.e. marking, safeguarding, transporting, disseminating, reusing and disposing of controlled unclassified information). This is to be in accordance with NIST 800-171 Rev.2 (see References and Standards). This applies to all building blocks that deal with CUI (usually information collected by govt and security agencies) which is likely to also be specific to country implementation. | Could be implemented | We have data classification, but we have no labelling still implemented, so we have no management rules for classified data already in place |
4.2.5.6 Controlled Unclassified Information (CUI) domain isolation (isolation for sub-networks and security domains etc. handling CUI) | Organizational Risk Rating: High | See above - requires a physically separate domain for hosting such information. | This is related to the above but the project SHOULD provide Controlled Unclassified Information (CUI) domain isolation (isolation for sub-networks and security domains etc. handling CUI). | Could be implemented | We have data classification, but we have no labelling still implemented, so we have no management rules for classified data already in place |
Cross-Cutting Requirements
Name | Description |
|
| Fit Gap Comments |
5.1 Privacy | Personal data MUST be kept private and never shared with any parties, except where specific authorization has been granted. This also applies to all acquired security components as they will often be logging personal data along with the transactional records. That logging data must also be considered private. Where CUI (Controlled Unclassified Information) is dealt with, the NIST 800-171 Rev 2 standard shall be applied (see Ref 3) |
| Could be implemented | Personal data functionality not implemented for a moment |
5.2 Security Requirements | Must refer reciprocally to this document and its references. |
|
|
|
5.5 Digital ID/Certificate Functional Requirements |
|
|
|
|
5.5.1 Enrollment Services | Enrollment services for a digital ID in the form of a certificate using the physical credentials of the enrollee (a human citizen subject) and the process of the Identity BB (see the functional requirements for Identity in the Identity BB Definition). A feature for invalidating, locking or disenrollment/revocation of the digital ID shall also be provided as a response measure to both human citizen subjects leaving the system and responding to security breaches encountered. Digital certificate enrollment must be provided by the solution but is not required for every human citizen subject (see below). Note that it is anticipated that the Identity BB will call this feature either directly via API or indirectly via the IAM features of the Security BB for users electing to use a digital ID consisting of certificates as a part of the account provisioning process. The digital ID will then be stored with the physical ID records in the identity BB and sent to the new user via secure means (probably installed on their device). Note that simple numerical digital IDs will also be supported for human citizen subjects as an option where users are unable to leverage certificates based digital ID. The requirements governing this are to be stipulated by the Identity BB (see the Identity BB Definition) . Note that 3rd party organization and internal subjects (both human and non-human) MUST be issued valid signed digital certificates in order to establish and maintain secure inter-organization and internal communications. | REQUIRED | Not the same approach | We are not enrolling any certificates, just using existing certificates issued to authenticate users |
5.5.2 Multi-Factor Authentication | The overall solution suite shall also be able to implement multi-factor authentication using simple numeric digital IDs for human citizen subjects such as their tax file or social security number of the user. A selection of various alternatives for digital ID is required in order to cater for more or less digitally-savvy citizens. Various token types are also required to be optimally supported such as HOTP and TOTP tokens, SMS, email, push notifications, SSH keys, X.509 certificates, Yubikeys, Nitrokeys, U2F and WebAuthn. Vendors of solutions SHOULD articulate the benefits of what they propose in their solution. Note that multi-factor authentication must be able to be implemented for both external and internal subjects (people, systems, components etc.) but is not necessarily required for internal non-human subjects (such as building block components) as they communicate via the information mediator BB (see the InfoMed BB Definition). | REQUIRED | Could be implemented | MFA is not implemented yet |
5.5.3 Numerical Digital ID Attribute | Where human citizen subjects adopt the use of a simple numerical digital ID, the multi-factor authentication process MUST include a time-sensitive credential (AKA OTP or one time PIN) | REQUIRED | Could be implemented | Not implemented yet |
5.6 Certificate Authority Functional Requirements |
|
|
|
|
5.6.1 Strong Authentication and Cryptography | The basic security service requirements of high confidentiality, high integrity, strong authentication, strong cryptography and absolute non-repudiation must be delivered by the solution. The vendor must articulate how these needs are met with the proposed solution suite to ensure that GovStack is able to deliver the same consistent security service experience | REQUIRED | Not applicable | We are not responsible for issuing certificates to be used to authenticate users. Separate government CA is responsible for issuing certificates |
5.6.2 Standards Based Certificate Authority Server | A certificate authority (CA), or certifier with fully configured server infrastructure, is required to implement trusted administration tools that issue signed digital certificates to citizens and other 3rd parties then maintain the lifecycle of those digital certificates Digital certificates MUST comply with the IETF, ISO/IEC/ITU-T X.509 Version 3 and PKIX (note that PKIX is the registration authority role, which allows administrators to delegate the certificate approval/denial process) standards as defined by RFC5280 and associated standards. Digital certificates are to be issued on behalf of the appropriate government authority where GovStack is to be deployed. | REQUIRED | Not applicable | We are not responsible for issuing certificates to be used to authenticate users. Separate government CA is responsible for issuing certificates |
5.6.3 Certificate Issuance | Issued signed digital certificates MUST verify the identity of an individual, a server, or an organization and allow them to use SSL to communicate and to use S/MIME to exchange mail as well as sign documents and transactions in a non-repudiable manner. | REQUIRED | Not applicable | We are not responsible for issuing certificates to be used to authenticate users. Separate government CA is responsible for issuing certificates |
5.6.4 Digital Signatures | Certificates issued by the authority MUST be stamped with the certifier's digital signature (i.e. signed), which assures the recipients of the certificate that the bearer of the certificate is the entity named in the certificate. | REQUIRED | Not applicable | We are not responsible for issuing certificates to be used to authenticate users. Separate government CA is responsible for issuing certificates |
5.6.5 Private Certifier Capability | The solution provided MUST be able to be set up as a certifier to avoid the expenses that a third-party certifier charges to issue and renew client and server certificates. In other words the solution can operate without a 3rd party certifier. This makes it easier, cheaper and quicker to set up and deploy new certificates as needed and at scale. Certificate validation will not be required to access a 3rd party certifier for validation. | REQUIRED | Not applicable | Service communication, which is required the certificate, is managed by Istio itself. All other communication-related certificates are issued by OKD's internal mechanism and we are not controlling this for a moment. |
5.6.6 Revocation Lists Support | The certificate server MUST be able to support certificate revocation lists (CRLs), which contain information about revoked or expired Internet certificates. | REQUIRED | Not applicable |
|
5.6.7 Flexible Certificate Authority Hierarchy | The certificate authority server infrastructure MUST enable CA administrators to create a flexible private CA hierarchy, including root and subordinate CAs, with no need for external CAs. Private CA hierarchies must be able to be built in a hybrid mode, combining online and on-premises CAs with cloud based CAs. | REQUIRED | Not applicable |
|
5.6.8 Web Based Admin Interface | The certificate authority server infrastructure MUST provide a comprehensive web based administrator user interface so that all of the GovStack certificate issuance and revocation features and functions can be configured and managed from a single central window. | REQUIRED | Not applicable |
|
5.6.9 Standards Based API Interface | The certificate authority server infrastructure must provide a secure API interface that supports calls for the issuance and revocation of certificates by other GovStack components such as the Identity Building Block. This API must comply with the same OpenAPI standards defined in the Architecture Blueprint (see Ref 1) | REQUIRED | Not applicable |
|
5.6.10 High Availability | The certificate authority server and its infrastructure must be configurable for highly available implementation (see the non-functional definitions for high availability). For example this means clustering and failover of certificate authority services and associated data sources to provide a 24x7x365 service with 99.99% availability (AKA 4 nines).. | REQUIRED | Not applicable |
|
5.6.11 Horizontal Scalability | The certificate authority infrastrastructure must be horizontally scalable on commodity hardware to ensure that the scalability needs of low resource countries with large populations deploying GovStack can be met without incurring significant or untenable costs. | REQUIRED | Not applicable |
|
5.6.12 Advanced Encryption Methods Support | The solution provided MUST support advanced encryption techniques such as ECC (Elliptic Curve Cryptography) which gives certificates an additional security/performance advantage vs use of the traditional RSA cryptography system for example. Other techniques may be acceptable and the vendor must explain and justify why they are superior. | REQUIRED | Not applicable |
|
5.6.13 Enrollment via API Interface (SCEP) | The solution MUST provide a means of enrollment via a standardized API interface which SHOULD be based on SCEP. A description of the OpenXPKI enrollment workflow and API can be found here: . This is an example only and can vary based on the proposed implementation. | REQUIRED | Not applicable |
|
5.6.14 Security Provisions | The certificate authority deployment scheme must be exposed to the public internet and protected securely in accordance with all of the other security requirements and provisions described in this document. The reason for this is to allow 3rd parties to verify the authenticity of certificates issued by the govts deploying GovStack. | REQUIRED | Not applicable | Only for publically available registries |
5.7 Credential Storage (i.e. LDAP) Functional Requirements |
|
|
|
|
5.7.1 Centralized Credential Store | The GovStack security solution requires a credential store as a centralized infrastructure for hosting the user account and credentials defined such that the IAM solution and other components such as the API Management and Gateway solutions can leverage them. This may end up being embedded in other solutions such as IAM or potentially implemented as a separate repository such as LDAP. | REQUIRED | Implemented | Keycloak |
5.7.2 Web Based Admin Interface | The solution provided as a credential store MUST have a comprehensive web based administrative interface that allows administrators to make any necessary configuration changes and modify credentials for subjects as needed. | REQUIRED | Implemented | Keycloak web admin interface |
5.7.3 High Availability | The solution provided as a credential store and associated components providing access to the store MUST be highly available and utilize clustering technology in order to provide a minimum of 24x7x365 service with 99.99% availability (AKA 4 9’s). | REQUIRED | Could be implemented |
|
5.7.4 Standards Based REST API |
| REQUIRED | Not the same approach | Keycloak not supporting LDAP REST API |
5.7.5 Standard Connectors and Adapters | The solution provided as a credential store must be fully integratable with the other security solution components through standards based protocols and out-of-the-box adapters for the specific product offered. | REQUIRED | Implemented |
|
5.8 Time Sensitive Credential (i.e. OTP) Functional Requirements |
|
|
|
|
5.8.1 OTP and Multifactor Capability | The solution must provide the ability to generate and utilize time sensitive credentials in various forms for the purposes of securing user authentication with multiple factors using non-PKI credentials (see the section of digital ID in this document). | REQUIRED | Could be implemented | OTP not implemented |
5.8.2 Multiple OTP Methods | Multiple methods SHOULD be provided for the implementation of time-sensitive OTP using potentially push or device level sources. Note that vendors SHOULD articulate the benefits of their technology and approach to implementing time sensitive credentials and align their recommendations to the needs of resource limited settings. | OPTIONAL | Could be implemented | OTP not implemented |
5.8.3 High Availability | The solution provided as an OTP server and any associated components MUST be highly available and utilize clustering technology in order to provide a minimum of 24x7x365 service with 99.99% availability (AKA 4 9’s). | REQUIRED | Could be implemented | OTP not implemented |
5.8.4 Standards Compliance | The solution offered MUST comply with at least one of the common OTP related IETF standards such as , RFC 1760 (S/KEY), RFC 2289 (OTP), RFC 4226 (HOTP) and RFC 6238 (TOTP). | REQUIRED | Could be implemented | OTP not implemented |
5.8.5 Standards Based REST API | The offered solution MUST provide a REST API for managing OTP similar to the following: . This is just an example and can vary with the proposed implementation. | REQUIRED | Could be implemented | OTP not implemented |
5.9 Network Scanning and Vulnerability Management Requirements |
|
|
|
|
5.9.1 Network Policy Definition and Scanning | The solution offered MUST provide advanced policy definition capabilities along with the ability to scan entire networks and subnetworks with one click and the ability to automate scanning on a regular schedule. | REQUIRED | Not applicable | The platform is not responsible for network scanning. Platform instance owners are accountable for this. |
5.9.2 Broad Suite of CVE Scan Coverage | The solution MUST provide the broadest possible suite of CVE (known vulnerability) scans across common ports for common software services and the like. | REQUIRED | Could be implemented | Scan of the nodes is a responsibility of platform instance owners |
5.9.3 Regular CVE Pattern Updates | The solution must provide regular updates and new plugins for emerging CVEs within a short timeframe of the CVE becoming known. | REQUIRED | Could be implemented |
|
5.9.4 List of Top Threats and Remediations | The solution MUST be able to assemble lists of top threats from scans, based on VPR and provide recommendations on which vulnerabilities pose the greatest risk in order to prioritize remediation efforts. | REQUIRED | Could be implemented |
|
5.9.5 Broad Range of Preconfigured Templates | The solution MUST provide preconfigured templates out-of-the-box for a broad range of IT and mobile assets. These must support everything from configuration audits to patch management effectiveness which helps quickly understand where vulnerabilities exist and assess audit configuration compliance against CIS benchmarks and other best practices. | REQUIRED | Could be implemented |
|
5.9.6 Customizable Views | The solution MUST provide the ability to easily create reports based on customized views, including specific vulnerability types, vulnerabilities by host or by plugin. MUST be able to create reports in a variety of formats (such as HTML, csv and XML) and then easily tailor and email reports to stakeholders with every scan. | REQUIRED | Could be implemented |
|
5.9.7 Associative Remediation | The solution SHOULD provide associative remediation via security patch automation using automation tools so that hundreds or even thousands of specific vulnerability instances can be addressed across the whole infrastructure. | OPTIONAL | Could be implemented | not applicable for pipeline related things |
5.9.8 Standards Compliance Management | The solution MUST provide the general ability to implement vulnerability management processes that drive compliance with PCI, HIPAA, GLBA, CIS, NIST and or similar European or African continental standards. | REQUIRED | Could be implemented |
|
5.9.9 Scalability | The offered solution MUST be able to scan whole large networks of computers with thousands of open ports and services within an acceptable time frame (the usual maintenance window). The vendor is to explain the scaling strategy and how it can be used to address a significant eGovernment infrastructure that serves millions of citizens.. | REQUIRED | Not applicable | The platform is not responsible for network scanning. Platform instance owners are accountable for this. |
5.10 Virus, Ransomware, Malware, Spam, Phishing Protection Requirements |
|
|
|
|
5.10.1 Transparent Gateway Service | The solution MUST provide an anti-spam mail gateway that transparently operates within the email routing infrastructure using standards based protocols such as SMTP, POP and IMAP. | REQUIRED | Could be implemented | Anti-spam not implemented |
5.10.2 Common Vulnerability Scans | The solution must be able to scan emails for various types of malware and for spam, phishing, and other types of malware common attacks that target known system infrastructure vulnerabilities. The solution must be extensible (perhaps by plugin) to support emerging threats, new vulnerabilities and new services. | REQUIRED | Could be implemented | Not implemented |
5.10.3 Cloud or On-Premise Deployment | The solution MUST provide a cloud-based or on-premise based pre-perimeter defense against spam, phishing emails and virus-infected attachments. | REQUIRED | Could be implemented | Not implemented |
5.10.4 3rd Party Virus Checker Support | The solution provided MUST support a wide range of 3rd party and open source virus checker software which is independent of the mail scanner module. | REQUIRED | Could be implemented | Not implemented |
5.10.5 Wide Range of Filtering Approaches | The solution provided MUST support a wide range of filtering approaches and analytic tests such as text analysis, DNS blacklists, collaborative filtering databases and Bayesian filtering. | REQUIRED | Implemented | We have DNS blacklist functionality in place |
5.10.6 Common Infrastructure Deployments | The solution MUST be deployable within common open source mail server infrastructures such as procmail, qmail, Postfix, and sendmail | REQUIRED | Could be implemented | Not implemented |
5.10.7 Ability to Integrate in Multiple Points | The mail scanning modules of the solution MUST be able to be integrated at any place in the email stream. | REQUIRED | Could be implemented | Not implemented |
5.10.8 Multiple Analytic Techniques | The solution MUST provide multiple analytic techniques, as well as in-depth human expertise, to score incoming email attachments as good, bad, or unknown | REQUIRED | Could be implemented | Not implemented |
5.10.9 Attachment Containment | The solution MUST run unknown attachment files in containment which is a completely virtual environment and isolated from other network segments. | REQUIRED | Could be implemented | Not implemented |
5.10.10 Day Zero Infection Prevention | The solution MUST provide the ability to protect from “day zero” infections by rapidly responding with automated updates to counter newly identified threats and applying pattern based algorithms to detect new threats before they infiltrate systems. | REQUIRED | Could be implemented | Not implemented |
5.11 Denial of Service Attack Prevention Requirements |
|
|
|
|
5.11.1 Application Layer Protection | The proposed solution MUST protect against application layer DDOS attack: Application Layer DDOS attack is a type of DDOS attack which targets the application layer of OSI model (i.e. the protocols that interface software modules such as POP, IMAP, SMTP, HTTP etc.). The size of these attacks are typically measured in requests per second (RPS) and limits must be configurable for both the singular IP addresses and subnets from which such traffic originates. | REQUIRED | Not applicable | No DDOS prevention system is provided by a platform. DDOS prevention will be organized by platform instance owners. |
5.11.2 Protocol Style Attack Prevention | The proposed solution MUST protect against Protocol style DDOS attacks: Protocol style DDOS attacks target server resources rather than bandwidth through saturation of requests synch as TCP SYN for connection attempts and general UDP frames in order to render the target services useless for users. The size of these attacks are typically measured in protocol frames per second (PFPS) and limits must be configurable for both the singular IP addresses and subnets from which such traffic originates. | REQUIRED | Not applicable |
|
5.11.3 Volume Based Attack Prevention | The proposed solution MUST protect against volume based DDOS attack: Volume based DDOS attack uses a variety of different techniques to saturate bandwidth of the attacked site, so other visitors cannot access it. It eventually leads the server to crash due to traffic saturation. There are three ways the solution MUST defend against volume based DDOS: 1) Attack Prevention and Preemption: this is before the attack based on detection of patterns. 2) Attack Detection and Filtering: This is performed during the attack and packets are filtered or dropped in order to preserve system integrity and 3) Attack Source Blacklisting: This can be performed during and after the attack. | REQUIRED | Not applicable |
|
5.11.4 White Lists | The proposed solution MUST support a white-list of addresses that will always be passed to the servers. This is to facilitate normal usr operations and reduce the likelihood of false positives. | REQUIRED | Not applicable |
|
5.11.5 Automatic Unblocking | Blacklisted or blocked IP addresses MUST be able to be automatically unblocked by the solution after a configurable timeout period. | REQUIRED | Not applicable |
|
5.11.6 Remediation Script Hooks | The solution MUST provide the ability to run hooks for remediation scripts at event edges or at defined intervals for the purpose of cleaning up server resources and ensuring system stability etc. | REQUIRED | Not applicable |
|
5.11.7 Alerting Framework | The solution MUST provide an alerting framework (via email and/or instant messaging) when IP addresses are blocked so that administrators are kept abreast of potential attacks and can begin monitoring activity more closely with a view to manually intervene if necessary. | REQUIRED | Not applicable |
|
5.11.8 Standard Firewall Integration | The solution MUST support and integrate with typical Linux firewall technologies such as APF (advanced policy firewall), CSF (config server firewall) and standard Linux iptables having the ability to insert and adjust rules into the firewall on the fly to cater for attack responses and remediation. | REQUIRED | Not applicable |
|
5.11.9 TCP Kill | The solution MUST provide the ability to kill TCP request processes upon encountering flooding in order to preserve the integrity of the protocol stack and return the system to a normal state where it is able to process TCP requests. | REQUIRED | Not applicable |
|
5.12 Applications Development Vulnerability Prevention Requirements |
|
|
|
|
5.12.1 OWASP Compliance | The custom developed applications solutions MUST take steps to protect against the top OWASP vulnerabilities such as XSS for example. Development processes MUST implement automated tooling to check code for such vulnerabilities. | REQUIRED | Implemented |
|
5.12.2 OWASP Source Code Scans | The solution provided MUST be able to scan source code committed to repositories by developers to identify and remediate the top OWASP vulnerabilities. Security hotspots pertain to the implementation of security sensitive code. Detection and human review using developer workflow is required to ensure that defects pertaining to security hotspots do not find their way into production code.. As developers code and consequently deal with security hotspots, they MUST also be able to learn how to evaluate security risks by example and error identification whilst continuously adopting better secure coding practices. The tooling provided for this MUST enable such a scenario to take place to drive continuous developer security improvement. Note that this pertains to custom coding for applications and components developed by all building blocks and not to the code behind 3rd party components and applications to which GovStack must be integrated. | REQUIRED | Implemented |
|
5.12.3 Support for Common Programming Languages | The solution provided should support common programming languages used in the enterprise such as Java, JavaScript, C, C++, C#, Python, Scala, Kotlin, Golang and PHP. | OPTIONAL | Implemented | We are supporting all of the languages we are using during development. |
5.12.4 Detection and Remediation of Top 10 Vulnerabilities | The solution provided must minimally support the detection and remediation of the following types of security vulnerabilities (based on the OWASP Top 10 for 2021):: | REQUIRED | Implemented | OWASP Zap scanner |
5.12.5 Common Developer Tools and Frameworks | The solution provided MUST integrate with common developer tools and frameworks as well as source code control systems such as GIT, SVN etc. and Jira for full cycle issue management. | REQUIRED | Implemented |
|
5.13 Infrastructure Vulnerability Remediation Requirements |
|
|
|
|
5.13.1 Container Scanning Features | The solution for containers (Docker and OCI) is presumed to be the main infrastructure layer for the project and it is this layer that requires protection from common vulnerabilities and exposures (CVE). The solution for containers MUST provide scanning tools to scan the content of deployed containers for known vulnerabilities with a view to reduce the attack surface for attackers. | REQUIRED | Implemented | Trivy used for docker containers scanning |
5.13.2 Fully Integrated DevSecOps | The solution for containers MUST have a fully integrated DevSecOps approach for CI/CD (continuous integration and continuous deployment) that prevents containers with known vulnerabilities from being deployed and enables patches for known CVE to be deployed both inside the container and to the container orchestration layer and its associated components (AKA PaaS). | REQUIRED | Implemented | Vulnerability scanning is a part of CI/CD pipeline |
5.13.3 Automatic Infrastructure Update | The solution for containers MUST address the problem of automatically updating the infrastructure on a regular and/or demand basis to apply security patches for known vulnerabilities as soon as they are available. The goal is to reduce the window of vulnerability for new CVE’s that are discovered. This is particularly in consideration of historical vulnerabilities that impacted hardware such as Spectre which impacted over 40M computers worldwide. | REQUIRED | Could be implemented | No automatic updates. A responsible person should trigger any update. |
5.13.4 FIPS 140-2 and ECC Certifications | The solution for container orchestration and its associated platform infrastructure MUST be certified as compliant with known security standards such as NIST FIPS 140-2 and the European Common Criteria certifications. | REQUIRED | Could be implemented | The registry platform follows cryptography from OWASP ASVS |
5.14 Data Loss and Leakage Prevention Requirements |
|
|
|
|
5.15.1 Multi-Channel Detection and Prevention | The solution MUST provide a multi-channel means of detecting and preventing data leakage for critical and private data over web, email, instant messaging, file transfer, removable storage devices and printers and any other file transfer means. | REQUIRED | Could be implemented | Registry platform using monitoring of file transfers inside a platform so we are prepared to onboard DLP system owned by oganisation. |
5.15.2 Fully Controlled Endpoint Protection | The solution MUST provide endpoint protection for data in use on systems that run on internal end-user workstations or servers. Endpoint-based technology MUST address internal as well as external communications. Endpoint technology MUST be used to control information flow between groups or types of users. It MUST also control email and instant messaging communications before they reach the corporate archive and block communication/consumption/transmission/forwarding of critical and sensitive data. | REQUIRED | Not applicable | Organisational topic to protect |
5.15.3 Confidential Information Identification | The solution MUST include techniques for identifying confidential or sensitive information. Sometimes confused with discovery, data identification is a process by which organizations use a data leakage prevention technology to determine what to look for. | REQUIRED | Could be implemented | Not implemented |
5.15.4 Ability to Implement Compliance Audits | The solution MUST provide the general ability to implement data loss and leakage prevention processes that drive compliance with PCI, HIPAA, GLBA, CIS, NIST and or similar European or African continental standards. | REQUIRED | Could be implemented | OWASP ASVS |
5.15 Data Encryption at Rest and In Transit Requirements |
|
|
|
|
5.15.1 Support for Standards Based Data at Rest Encryption | The solution (all components hosting sensitive data, personal data, credit card data or CUI) is required to be able to support the encryption of data at rest using standard strong encryption techniques such as ECC and RSA with certificate based PKI (i.e. X509 etc.). The certificates and PKI infrastructure used for this purpose MUST comply with the requirements stipulated in this document for digital identity. The solution vendors for 3rd party components should articulate how each of the components supplied provides data encryption facilities for data at rest and the strength and benefits of their approach. This also applies to all components hosting data for all building blocks. | REQUIRED | Could be implemented | Relational DB storage encrypted |
5.15.2 Support for Standards Based Data in Transit Encryption | All of the internal connections between the various components in each building block and between building blocks as well as the external connections for API calls etc. between web and mobile applications and their respective services must be encrypted for data in transit using standard strong encryption techniques such as ECC and RSA with certificate based PKI (ie. X509 etc.). The certificates and PKI infrastructure used for this purpose MUST comply with the requirements stipulated in this document for digital identity. The solution vendors for 3rd party components should articulate how each of the components supplied provides data encryption facilities for data in transit and the strength and benefits of their approach. This also applies to all components communicating data between all building blocks. | REQUIRED | Could be implemented | Relational DB connections - encrypted |
5.16 Social Network, Media and Engineering Threat Management Requirements |
|
|
|
|
5.16.1 Social Threat Mitigation | The project MUST mitigate these types of threats with a combination of policy, training and technology. Many of the attacks in this style are initiated through phishing and dangerous email attachments. It is therefore anticipated that much of the technical aspects of mitigating these types of attacks can be addressed through the requirements identified elsewhere in this document. Cyber-criminals use a range of attack styles leveraging social networking, engineering and media to achieve a range of goals: for example to obtain personal data, hijack accounts, steal identities, initiate illegitimate payments, or convince the victim to proceed with any other activity against their self-interest, such as transferring money or sharing personal data” The most frequent styles of attack include: | REQUIRED | Not applicable | Platform instance owners responsible for mitigating this kind of vulnerabilities |
5.17 Cloud Security Posture Management Requirements |
|
|
|
|
5.17.1 Continuous Posture Assessment | The project MUST deliver continuous cloud security posture assessments of cloud environments through security and compliance teams. The solution must be able to manage the massive number of security posture management issues that will confront the project as infrastructure is deployed on public clouds with even modest deployments. The solution MUST be able to provide an assessment approach which addresses all of the common security concerns accompanying public cloud based deployments using containers, kubernetes and other public cloud services etc.. The key requirements are both taking control of; and keeping control of security risks in multiple, ever-growing and ever-changing cloud environments. Typically it is just too much data to process, too often, with an ever-expanding attack surface as more applications and services are deployed. This is the problem space that MUST be dealt with by the proposed solution and why continuous cloud security posture management is an absolute MUST for cloud deployments. Note that GovStack may be deployed either on cloud infrastructure, on premise infrastructure or both. The intent of the CSPM requirements is for public cloud deployments although it can also be utilized for controlling on-premise public cloud offerings such as Azure Arc or AWS Outposts.. | REQUIRED | Not applicable | We are not responsible for assisting the cloud data center from the digital platform. This is the responsibility of the owner of the platform instance. |
5.17.2 Inventory, Ownership and Customization | In terms of the inventory of data and services deployed, the following MUST be able to be managed (see ensuing rows) | REQUIRED | Not applicable |
|
5.17.3 Inventory Collection Coverage | Must collect the metadata from all available cloud resources that have been deployed and utilized in the account. This collection MUST go beyond the core types of services (compute, networking, database, and IAM etc.) to incorporate a complete security metadata view of the utilized cloud resources and any potential exposures both inside and outside containers. | REQUIRED | Not applicable |
|
5.17.4 Data Ownership | Solutions delivered as Software-as-a-Service (SaaS) provide quick onboarding, but they are typically managed by third-party with account-wide access to your cloud resources. This may present challenges with data ownership, compliance attestations of an external third party, and adherence to regional compliance mandates. These issues MUST be identified by CSPM. | REQUIRED | Not applicable | This is the responsibility of cloud owner |
5.17.5 Customization | 3rd party solutions can vary widely in their ability to make adjustments to how data is collected, how security checks are implemented, how results are filtered/excluded and reported, and how and when teams are alerted for issues. Without full control over all aspects, you may end up with results and notifications that cannot be properly tuned, and this can lead to ignoring the tool and overall alert fatigue. The CSPM solution MUST provide the ability to navigate the posture across all 3rd party components and alleviate alert fatigue. | REQUIRED | Not applicable |
|
5.17.6 Answer Complex/Advanced Questions | Simple questions like “Is this S3 Bucket Public?” can usually be identified easily, but questions like “Are there any publicly accessible virtual machines with attached instance credentials that allow reading from S3 buckets tagged ‘sensitive’?”, “Which GKE Clusters have pods with access to escalate to ‘Project Owner’ via the attached Service Account? MUST be able to be answered by the CSPM solution” | REQUIRED | Not applicable |
|
5.17.7 Provide Continuous Results and Triage | The CSPM solution MUST be designed with tunable results tracking and results triage workflows across multiple assessment intervals for continuous assessment as the total deployed solution evolves. | REQUIRED | Not applicable |
|
5.17.8 Focus on both Hardening and Compliance | Most security practitioners are aware of the differences between an environment that is only compliant with one that is compliant and also well hardened. Compliance is a key driver for obtaining project funding and being able to operate a business legally, but going no further than compliance still leaves you open to critical risks. The CSPM tools MUST cover both security best practices and compliance objectives equally. | REQUIRED | Not applicable |
|
5.17.9 Compliance Objectives Driven Approach | The solution MUST be able to associate controls with one or more compliance objectives. Views, filtering, and workflows should be driven by compliance objectives. For example, filtering controls by “PCI”, “NIST 800-53”, or “CIS” should narrow down the list to the controls that align with those frameworks with an identical mechanism that can also be used to filter controls for “lateral movement” or “privilege escalation”. | REQUIRED | Not applicable |
|
5.17.10 CSPM Basics | The CSPM solution MUST address the basic cloud security posture management abilities as defined above for the broadest range of public cloud infrastructure providers (for example AWS, GCP and Azure). The following basic activities MUST be supported: | REQUIRED | Not applicable |
|
5.19 Vulnerability Management and Security Automation Requirements |
|
|
|
|
5.19.1 Security Automation in General | In general the vulnerability scanning requirements are covered in other sections of this document. The focus of this requirement is automation of vulnerability management to limit the window of vulnerability to be as short as possible once a vulnerability becomes known. The project MUST implement security automation which means automated patching and upgrades of the software and firmware in and around the applications and networking infrastructure to ensure that patches addressing security vulnerabilities are deployed consistently across all of the infrastructure. | REQUIRED | Implemented | We have IAC, so no manual work is required for any deployment required things |
5.19.2 Repeatability for both Cloud and On-Premise Deployments | The security automation solution MUST provide a clean, consistent, simple and repeatable means of configuration management, applications deployment and patching that is flexible enough to support the entire infrastructure including both on-premise and cloud based deployments. Typically this would be achieved with a playbook style approach where playbooks are built using a language such as YAML and applied consistently through an automated scripting approach. | REQUIRED | Implemented | Helm charts |
5.19.3 Agentless Orchestration and Provisioning | The solution MUST provide orchestration, provisioning, module, plugin and inventory management support in order to be comprehensive for enterprise needs. Ideally the solution provided MUST be agentless and not require any additional software to be deployed on each node in the network. | REQUIRED | Implemented | Solution built on top of OKD |
5.19.4 Consistent Configuration Management | The solution MUST provide simple, reliable, and consistent configuration management capabilities. Must be able to be deployed quickly and simply with many out-of-the-box plugins for common technologies. Configurations MUST be simple data descriptions of infrastructure which are both readable by humans and parsable by machines. The solution itself MUST be able to connect to remote nodes under administration via SSH (Secure Socket Shell) key for secure configuration. For example configurations MUST be able to be consistently applied to hosts via lists of IP addresses and apply playbooks to install the configuration update on all the nodes. Subsequently the playbook can be executed from a control machine to effect the update. Logs MUST be taken and reported on to ensure that centralized admin is aware of any failure and can address them manually if necessary | REQUIRED | Implemented |
|
5.19.5 Orchestrated Workflows | The offered solution MUST provide orchestration which involves bringing different elements together to run a whole operation. For example, with application deployment, you need to manage not just the front-end and backend services but the databases, networks and storage among other components. The orchestration solution MUST also ensure that all the tasks are handled in the proper order using automated workflows and provisioning etc.. Orchestations and playbooks MUST be reusable and repeatable tasks that can be applied time and again to the infrastructure based on parameters. | REQUIRED | Implemented |
|
5.19.6 Site-wide Security Policy Implementation | The solution MUST have the ability to implement sitewide security policies (such as firewall rules or locking down users) which can be implemented along with other automated processes. MUST be able to configure the security details on the control machine and run the associated playbook to automatically update the remote hosts with those details. This means that security compliance should be simplified and easily implemented. An admin’s user ID and password MUST NOT be retrievable in plain text. | REQUIRED | Implemented |
|
5.21 Intrusion Prevention and Detection Requirements |
|
|
|
|
5.21.1 HIDS, SIM and SIEM with Real-Time Integrity Monitoring | The solution for intrusion prevention and detection MUST combine HIDS monitoring features with Security Incident Management (SIM)/Security Information and Event Management (SIEM) features. MUST also be able to perform real-time file integrity monitoring, Windows registry monitoring, rootkit detection, real-time alerting, and active response. | REQUIRED | Could be implemented |
|
5.21.2 Multi-Platform Support | The solution MUST be multi-platform and support deployment on Windows Server, and most modern Unix-like systems including Linux, FreeBSD, OpenBSD, and Solaris etc.. The reason for this is that it is yet to be determined exactly which O/S infrastructure will be required for the full GovStack solution and it will likely end up being a hybrid mix of various O/S platforms but predominantly Linux in containers. | REQUIRED | Implemented |
|
5.21.3 Centralized Management | The intrusion prevention and detection software MUST consist of a central manager for monitoring and receiving information from agents (most likely agents are required - they are small programs installed on the systems to be monitored. Of course an agentless solution will be acceptable if it is feasible). The central manager MUST include storage of the file integrity checking databases, logs, events, and system auditing entries. | REQUIRED | Not applicable | SIEM out of scope |
5.21.4 Basic IDS Features | The intrusion prevention and detection solution MUST minimally offer the following features: | REQUIRED | Could be implemented | Most of features could be implemented by container-based IDS Sysdig Falco |
5.22 Open Source Intelligence Platform (OSINT) Requirements |
|
|
|
|
5.22.1 General OSINT Requirements | The project MUST provide OSINT tools with the following purposes and general requirements in focus (see ensuing rows): | REQUIRED | Not applicable | This is the responsibility of platform instance owners |
5.22.2 Discovery of Public-Facing Assets | The most common function of OSINT tools is helping IT teams discover public-facing assets and mapping what information each possesses that could contribute to a potential attack surface. This is public information about vulnerabilities in services and technologies that cyber-criminals can potentially use to gain access. In general, these tools don’t typically try to look for things like specific program vulnerabilities or perform penetration testing but may also incorporate these features. The main purpose of OSINT tools is determining what information someone could publicly discover about the organization's assets without resorting to hacking and offer security professionals the opportunity to proactively address these vulnerabilities by reading the reports. | REQUIRED | Not applicable | This is the responsibility of platform instance owners |
5.22.3 Discover Relevant Information Outside the Organization | A secondary function that some OSINT tools perform is looking for relevant information outside of an organization, such as in social media posts or information posted at specific domains and locations that might be outside of a tightly defined network. Organizations which have acquired a lot of diverse IT assets are excellent candidates for OSINT tools and we see that this has huge potential for GovStack. Given the extreme growth and popularity of social media, looking outside the organization perimeter for sensitive information is helpful for just about any group. | REQUIRED | Not applicable | This is the responsibility of platform instance owners |
5.22.4 Collate Discovered Information into Actionable Form | Finally, some OSINT tools help to collate and group all the discovered information into useful and actionable intelligence. Running an OSINT scan for a large enterprise can yield hundreds of thousands of results, especially if both internal and external assets are included. Piecing all that data together and being able to deal with the most serious problems first can be extremely helpful. The solutions offered MAY also incorporate AI/ML and neural network based solutions for better discovery and automation of analytics etc. | REQUIRED | Not applicable | This is the responsibility of platform instance owners |
5.22.5 Open Source Offering | The offered solution MUST be based fully on open source components. The vendor may offer subscriptions for support so long as the offered solution does not require those subscriptions in order to deliver the core functionality specified in this document. | REQUIRED | Not applicable | This is the responsibility of platform instance owners |
5.23 Fraud Prevention, Detection and Management Requirements |
|
|
|
|
5.23.1 Identify Fraudulent Purchases and Transactions | The solution MUST provide the ability to identify potentially fraudulent purchases, transactions, or access. The solution MUST continuously examine user behavior, and analyse risk figures then identify any suspicious activity that may require intervention. | REQUIRED | Could be implemented | not implemented |
5.23.2 General Features Required | The solution MUST be able to check the potential of fraudulent actions by users both internal and external, ensuring that transactions are lawful and genuine. The solution MUST also protect the sensitive information of both organizations and citizens (also see data leakage prevention). The solution MUST meet the following general features requirements: | REQUIRED | Could be implemented | not implemented |
5.23.3 Fraud Information Dashboard | The solution MUST provide an information dashboard with data visualization of statistical information and alerts pertaining to fraud prevention and detection that need to be addressed with an assigned priority. | REQUIRED | Could be implemented | not implemented |
5.23.4 Data Import from Many Sources | The solution MUST provide the ability to import data sets from many applications and databases in order to perform analysis and provide fraud analysis and scoring information along with alerts on configurable events and thresholds. | REQUIRED | Could be implemented | not implemented |
5.23.5 CRM Integration | The solution MUST provide integration with common customer relationship management solutions that are likely to be deployed as part and parcel of GovStack or perhaps already existing in the government's target architecture. | REQUIRED | Could be implemented | In this case, we do need to integrate with any customer CRM this should be done for each CRM separately, and no common solution could be provided here. |
5.23.6 API for Data Integration | The solution MUST provide an open API for the purposes of integrating data from unknown sources to be checked for fraudulent activity. | REQUIRED | Could be implemented | not implemented |
5.23.7 AI/ML Based Capabilities | Ideally the solution SHOULD incorporate advanced AI and ML capabilities for the purposes of detecting fraud with a combination of neural network, pattern recognition and data mining approaches to identify potentially fraudulent events based on advanced models and historical learning. | OPTIONAL | Could be implemented | not implemented |
5.23.8 Investigator Notes and Workflows | The solution MUST provide investigator notes and workflow capabilities for investigating potentially fraudulent incidents and managing those incidents through to resolution. | REQUIRED | Could be implemented | not implemented |
5.24 Security Incident Response and Management Requirements |
|
|
|
|
5.24.1 General Incident Response Requirements | The solution MUST provide an incident response and management system that implements the following general requirements as a fully integrated solution (referring to the other sections of this document): | REQUIRED | Not applicable | This could be done only by introducing separate organisational units inside the organisation, so it could not be addressed in the scope of platform software |
5.24.2 Support for NIST and/OR SANS | In general the NIST and/or SANS incident response frameworks SHOULD be followed and the tooling MUST facilitate this. | REQUIRED | Not applicable |
|
5.24.3 Assessment and Review Facilities | The solution MUST provide capabilities for reviewing and documenting existing security measures and policies to determine effectiveness as well as performing a risk assessment to determine which vulnerabilities currently exist and the priority of your assets in relation to them. This Information is then applied to prioritizing responses for incident types and is also used to reconfigure systems to cover vulnerabilities and focus protection on high-priority assets. This phase is where you refine existing policies and procedures or write new ones if they are lacking. These procedures include documenting a communication plan and the assignment of roles and responsibilities during an incident. | REQUIRED | Not applicable |
|
5.24.4 Tools to Support Detection and Identification | The solution MUST support the use of the tools and procedures determined in the preparation phase and define the process and teams to work on detecting and identifying any suspicious activity. When an incident is detected, team members need to work to identify the nature of the attack, its source, and the goals of the attacker. During identification, any evidence collected MUST be protected and retained for later in-depth analysis. Responders MUST document all steps taken and evidence found, including all details. The purpose of this is to more effectively prosecute if and when an attacker is identified. | REQUIRED | Not applicable |
|
5.25.5 Support for Communications Planning | After an incident is confirmed, communication plans MUST be initiated by the system. These plans MUST inform all concerned parties by workflow (i.e. security board members, stakeholders, authorities, legal counsel, and eventually users of the incident) advising which steps MUST be taken. | REQUIRED | Not applicable |
|
5.24.6 Threat Containment and Elimination | The solution and its processes MUST support the containment and elimination of threats. After an incident is identified, containment methods are determined and enacted. Containment: | REQUIRED | Not applicable |
|
5.24.7 Recovery, Restoration and Refinement | The solution MUST support a recovery, restoration and refinement phase where recovery and restoration of damaged systems is achieved by bringing last-known-good versions online. Ideally, systems can be restored without loss of data but this isn’t always possible. Teams MUST be able to determine when the last clean copy of data was created and restore from it. The recovery phase typically extends for a while as it also includes monitoring systems for a while after an incident to ensure that attackers don’t return. | REQUIRED | Not applicable |
|
5.25 Security Testing and Sandbox Requirements |
|
|
|
|
5.25.1 Comprehensive Sandbox | The proposed solution MUST include a security sandbox environment with instances of the entire software stack and all of the security tools installed and configured such that security testing and scenarios can be addressed on an ongoing basis. This is not so much a solution requirement as a deployment requirement and MUST address all of the processes associated with each of the facets of security defined herein. | REQUIRED | Implemented | We do have a sandbox for the security team |
5.25.2 Scalability | The security sandbox environment MUST scale to a level that is suitable for testing scenarios such as DDOS prevention etc. but does not have to be implemented at the same scale as the regular test environment or the production environment for example. | REQUIRED | Could be implemented | No DDOS protections implemented for a moment |
5.25.3 Test Scripting and Automation | The project MUST conduct security testing using automated scripts as much as possible on an ongoing basis and the security team MUST take ownership of the ongoing securitization of all digital assets for each and every deployment. Note that the responsibility for these activities may ultimately be delegated to a government or country team in the case of build-X-transfer implementation scenarios. The role of the solution provider is to ensure that the baseline for these processes is established prior to any handover/transfer. | REQUIRED | Implemented | All of the checking tools triggered in a CICD pipelines |
5.26 Critical Digital Infrastructure Business Continuity Requirements |
|
|
|
|
5.26.1 General Recovery Requirements | The solution MUST cater for the recovery of all critical digital infrastructure in the case of major security incidents. Refer to the section above regarding the indecent response system for the general requirements regarding how such recovery MUST be performed. | REQUIRED | Implemented | Manual/semi-manual recovery steps could be described in documentation |
5.26.2 Backup for Code and Images | The backup and recovery systems for code, system images and data MUST cater for complete recovery of all critical digital infrastructure after natural disasters and also security incidents. The detailed requirements for such recovery of systems are to be provided by each building block as custodian of the code, images and data. Detailed information on the specific recovery requirements MUST be provided by the project for each GovStack implementation as they may vary widely due to constraints on budget and capabilities. | REQUIRED | Implemented |
|
5.27 Data Structures |
|
|
|
|
5.27.1 Resource Model | The resource model shows the relationship between data objects that are used by this Building Block. The following resource model depicts the basic elements of identity and access management (IAM) solutions required organized into domains: |
|
| All of the model items have separate dedicated requirements, so reviewed in a scope of each separate requirement |
5.27.2 Data Elements | The data elements provide detail for the resource model defined above. This section will list the core/required fields for each resource. Note that the data elements can be extended for a particular use case, but they must always contain at least the fields defined here. Information about data elements will include: |
|
| All of the model items have separate dedicated requirements, so reviewed in a scope of each separate requirement |
Security Building Block Modules
Name | Description |
|
|
| Fit Gap Comments |
|---|---|---|---|---|---|
6.1 API Management and Gateway Functional Requirements |
|
|
|
|
|
6.1.1 Multiple API Gateway | The ability to implement segregated gateways for both internal and external API traffic. This means that the internal API driven integration traffic and the external API access traffic is to be segregated into separate gateway infrastructure components and access controlled by networks and network access policy. | MUST | deploy | Not the same approach | We have a separation of API gateway per subsystems groups (lets say separate API gateway for admin tools) |
6.1.2 Standards Based Identity and Access | The ability to implement standardized authentication, authorization and encryption protocols including federated identity (OAuth2, OpenID Connect, SAML2, SSO, SSL, TLS etc.). These standards MUST be supported and incorporated into any chosen API Management product out-of-the-box for controlling access to API interfaces. Note that the native API interfaces for each building block's components may be implemented in clear text with no authentication and/or encryption etc. so long as the access to these interfaces is firewalled by network and network policy such that it is ONLY accessible through the API Gateway. This is intended to simplify, standardize and expedite API development, deployment and management. Note that the APi interface specifications for the APi gateway and API management services are based on open standards based identity and access which is in turn based on OpenAPI 3.0. The following link describes how OAuth2 is used in OpenAPI 3.0 standards based identity and access: https://swagger.io/docs/specification/authentication/oauth2/. It is this style of standards based identity and access that is required to be supported, Note that additional API interfaces may be exposed by the API Management and Gateway solution but they would predominantly be targeted for incorporation into the DevOps CI/CD tool chain not exposed to other BBs. | MUST | build | Implemented | Implemented, OAuth2, OpenID, SSO, SSL, TLS |
6.1.3 Identity Store Plugins | The ability to utilize separate identity stores as repositories for identity and perform proxied authentication to such repositories (for example LDAP) using multiple credentials including digital identity certificates. | MUST | Both | Implemented | keycloak |
6.1.4 API Protection Features | The ability to support many security and protection features such as Standard API keys, App-ID key pair, IP address filtering, Referrer domain filtering, Message encryption, Rule-based routing, Payload security, Channel security, Defense against common XML and JSON attacks, Low- to no-code security configuration, PCI compliance.
Note that this is not an exhaustive list and additional policy protection features may strengthen the value of any given solution. | MUST | deploy | Implemented | Currently, the Rest API is protected using JWT tokens validation. Additional security features could be applied as well. |
6.1.5 Centralized API Policy Based Access | The ability to implement policy based access management for API endpoints. The policy MUST be able to be implemented centrally then applied across multiple gateways and all API endpoints. | MUST | deploy | Could be implemented | If this point about whitelist IP range, we do not support the global allowlist ip range defined for all of the gateways on a platform |
6.1.6 API Endpoint Transformation | The ability to support multiple standards for proxying endpoints and exposing them as standard OpenAPI endpoints (see Ref 1) including transformations such as XML ↔ JSON and SOAP ↔ RE Note that this is not an exhaustive list of the required transformations and that additional transformations may reinforce the strength of a solution’s flexibility and adaptability. | MUST | deploy | Implemented |
|
6.1.7 Alternative API Protocols | The ability to support multiple common protocols such as JMS, WS, MQTT. Note that this is not an exhaustive list and that additional alternative protocols supported may strengthen the value of the proposed solution. | MUST | deploy | Implemented | We have the ability to support any of mentioned protocols inside a platform |
6.1.8 API Versioning and Lifecycle | The ability to support multiple API versions and control multiple API versions and API lifecycle management. Note that there are many potential features available to strengthen the solution proposition such as version dependency management and deployment rollback etc. | MUST | deploy | Implemented |
|
6.1.9 API Call Traffic Shaping | The ability to implement traffic transformation and traffic shaping. This is typically implemented as single/dual rate, private (per node) and shared (by multiple nodes) shapers. Note that additional traffic shaping capabilities may strengthen the solution proposition. | MUST | deploy | Not applicable | Platform instance owners responsible for this |
6.1.10 API Call Rate Limiting | The ability to implement rate limiting for API calls on an API-by-API basis. This limits the rate at which API’s can be called by a consumer (for example 100/second etc.) and usually has many flexible options and caters for policy driven rate limits based on busy times etc. Principally it comes down to the offered SLA. Support for complex SLA construction may strengthen the solution proposition. | MUST | deploy | Implemented |
|
6.1.11 API Call Quotas | The ability to implement quotas for API calls from specific clients (daily, weekly, monthly etc.). This restricts the number of API calls a client can make and also often includes flexible options so that a complex SLA can be constructed. Support for complex SLA construction may strengthen the solution proposition. | MUST | deploy | Could be implemented | Not implemented, limits could be applied per user, but not for specific user |
6.1.12 API Call Logging, Monitoring and Alerts | The ability to implement logging and monitoring of API calls with reporting and administrative alerts. Typically extensive functionality with multiple logging levels is implemented. Support for flexible levels of logging (for example debug, trace etc.) may strengthen the solution proposition. | MUST | deploy | Could be implemented |
|
6.1.13 API Call Analytics | The ability to implement advanced analytics with out-of-the-box charts and reporting on demand along with the ability to trigger alerts based on analytics. The strength, flexibility, feature set and appeal of the analytics and charting capabilities may strengthen the solution proposition. Note that this can optionally be implemented as a separate tooling layer perhaps using tools such as Prometheus and Grafana etc. | MUST | deploy | Could be implemented |
|
6.1.14 API Virtualization | The ability to implement virtualized API endpoints. API virtualization is the process of using a tool that creates a virtual copy of your API, which mirrors all of the specifications of your production API, and using this virtual copy in place of your production API for testing. Note that this is NOT API mocking but provides an actual endpoint for solution testing to proceed unhindered. | MUST | deploy | Could be implemented | Sandbox environment could be treated as virtualised RestAPI env |
6.1.15 API Developer Portal | The ability to publish API specifications through a developer portal using open standards. Includes features such as portal availability across deployment types (on-premise, cloud, etc.), interactive API documentation, developer metrics, developer portal templates, portal customization (HTML, CSS etc.), ability to withdraw developer keys, either temporarily or permanently. Note that advanced developer portal features may strengthen the value of the solution proposition. | MUST | deploy | Implemented | Admin portal could be treated as developer portal, and changing a data structure will lead to the automatic change of data factory RestAPI specification. If the developer portal here is just an informational portal for developers, we also could publish RestAPI OpenAPI specification into documentation and make it available via HTTP using Antora. |
6.1.16 Flexibility in API Deployment Architectures | The ability to support a diverse array of deployment architectures including standalone, on-premise cloud and public cloud models including the ability to support a fully integrated microservices architecture based on containers. The architecture should also allow for the separation of key components and interfaces for meeting complex network security needs. Note that the more flexible the deployment architectures are, the stronger the solution proposition. | MUST | deploy | Implemented | The cloud-ready solution could be deployed on-premise as well as public cloud. Single platform installer package responsible for deploying an application to supported cloud providers or on-prem. |
6.1.17 Advanced DevOps Artefact Deployment | The ability to support advanced DevOps deployment techniques such as “canary deployment”, “blue-green deployment” and “AB testing”. Additional advanced deployment scenarios and innovations will strengthen the value proposition of the proposed solution. | MUST | deploy | Not the same approach | Not designed to be so |
6.1.18 File Storage Integration | The ability to implement file storage platform integration such as S3 etc. - not exhaustive. Note that flexibility in the support for storage integration across additional file storage standards will strengthen the value of the solution proposition. | MUST | deploy | Implemented | Implemented |
6.1.19 API Monetization | The ability to monetize API calls by specific 3rd parties or partners for the purposes of simply raising capital or creating partnership incentives through 3rd party portals. Features such as billing support, support for multiple models of revenue generation, low- to no-code monetization configuration, third-party payment system integration, prepay and/or postpay invoicing, multi-currency support and tax compliance are negotiable. Note that the more advanced the monetization features are, the higher the solution value proposition is. | SHOULD | deploy | Not the same approach | No monetization and payments currently designed |
6.1.20 High Availability | The solution provided and any associated components MUST be highly available and utilize clustering technology in order to provide a minimum of 24x7x365 service with 99.99% availability (AKA 4 9’s). | MUST | deploy | Could be implemented |
|
6.1.21 Open Source Based | The offered solution MUST be based fully on open source components. The vendor may offer subscriptions for support so long as the offered solution does not require those subscriptions in order to deliver the core functionality specified in this document. | MUST | build | Implemented |
|
6.2. Identity and Access Management (IAM) Suite Functional Requirements |
|
|
|
|
|
6.2.1 Identity Lifecycle Management | The following diagram defines the basic lifecycle required for managing identities: | MUST | deploy | Not the same approach | We do not follow lifecycle identity management for now. We have no de-provisioning phase and self-registration |
6.2.2 User Administration Tools | These are required so that administrative users and/or help desk users can centrally manage all user profiles and records. These features include: | MUST | Both | Could be implemented | No dedicated identity and access management system, only Keycloak WebUI |
6.2.3 Multi-Source Identity Integration | Integration with multiple source identity systems (such as the Identity BB, databases and LDAP) to automatically initiate provisioning/deprovisioning activities related to enrollment, policy changes and un-enrollment processes. | MUST | deploy | Implemented |
|
6.2.4 Multi-Source Identity Synchronization | Multi-source synchronization of user identity data. This allows the system to integrate and synchronize with an authoritative source such as the national ID, social security system or perhaps more likely the Identity BB via an API/plugin approach. This is required for both initial load of identities and for ongoing provisioning, re-provisioning and deprovisioning etc.. The synchronization must determine which systems a user should be provisioned to/de-provisioned from, which permissions should be set or revoked for the applications that a person is entitled to and whether or not provisioning should be automatic or if an additional workflow should be triggered for human or other automated processing. | MUST | Both | Implemented | No initial load functionality and de-provisioning |
6.2.5 Identity Reconciliation | Automatic user identity record reconciliation. This is where synchronization is used to detect changes in the source system identity data and reconciliation is used to detect, compare and resolve the changes. For example a user record has been added to a target system manually instead of using this case reconciliation can be configured to either: | MUST | deploy | Not applicable | We do not have separate credentials storage in each of the components. We are using central credential storage for entire digital platform |
6.2.6 Self Service Portal and Workflow | A customizable, workflow driven, self-service user interface portal to enable administrators to create and manage policies, users and the various artefacts. Must support approval workflows to multiple stakeholders. | MUST | deploy | Not the same approach | We do not have a self-service portal for citizens and officers. Authorisation possible only via ID provider or using certificate, which is managed by 3'rd party applications |
6.2.7 Advanced Password Management | The advanced password management capabilities must include the following: | MUST | deploy | Not the same approach | We do not have a self-service portal for citizens and officers. Authorisation possible only via ID provider or using certificate, which is managed by 3'rd party applications |
6.2.8 User Access Request Management | Whilst provisioning processes can be triggered through the automated user lifecycle management functionality, the IAM solution must also provide a self-service feature through the portal via which end-users can request access. This access-request functionality is provided through a shopping cart and service catalog design where the user has access to select the services to which they would like to request access. Applications and application-specific entitlements such as membership to an LDAP group or a role on a public cloud provider such as AWS must be supported as a part of the access grant process. The access request feature must also include the optional selection of a “Profile Role” capability – which is a role defined for a job/position that can grant access to a number of applications that are needed for a particular job role (otherwise known as delegation). The access request/approval workflows provided must support: | MUST | deploy | Not the same approach | We support only automatic provisioning of identities |
6.2.9 REST API | A REST (representational state transfer) based API for external integration of the provisioning and deprovisioning of users etc.. is required. It must support the same OpenAPI standards defined by the Architecture Blueprint and Functional Requirements (see Ref 1). An example of such a REST API is provided with the OpenIAM suite specification here: . This is intended as an example of the API style that is expected in such a suite. This is not definitive and may vary based on the proposed IAM suite. | MUST | deploy | Not the same approach |
|
6.2.10 Orphan Management | Organizations which are not actively using an IAM platform often have orphaned user records in their business applications. These are those records which are the result of users being given access and not having that access revoked when a person is unenrolled from a service. Orphan management functionality consolidates all the orphaned records and provides administrators with tools to either clean up these records or link them to the correct user. | MUST | deploy | Not the same approach |
|
6.2.11 Access Certification | Regulatory requirements, such as GDPR, HIPPA and SOX combined with an increased focus on security are causing both public and private organizations to implement access certification policies. Scheduled access certification campaigns aid in complying with these regulatory mandates as well as improve security by guarding against the access violations which lead to security breaches. However, when performed manually, these activities can be error prone and very time consuming for most mid to large organizations. The lack of consistency resulting from manual processes results in failed compliance audits and threats resulting from unauthorized access can slip undetected. The IAM solution must provide the ability to automate the access certification process which addresses the challenges found when performing these processes manually. The following types of certifications must be supported by the IAM solution: | MUST | deploy | Could be implemented |
|
6.2.12 Workflow Creation | The IAM solution identity governance feature set must provide the creation of workflows to support complex processing, integration and approval steps. While custom workflows must be defined, the IAM solution must also provide default out-of-the-box workflow templates for common operations to simplify the configuration effort. Each of these workflows must support: | MUST | deploy | Could be implemented |
|
6.2.13 Custom Workflows | Whilst the IAM solution must provide the above workflow templates, it also must include a BPMN compliant workflow engine that can be used to create new custom workflows. A graphical process designer such as the BPMN designer plugin such as one of the many available for the Eclipse IDE or similar must be included to simplify the effort required to create new custom workflows. | MUST | deploy |
|
|
6.2.14 Audit and Compliance | Facilitating compliance with regulatory requirements or internal security policies is one of the principal drivers for Identity Governance. The IAM solution must provide tools to help organizations meet compliance mandates. Organizations deploying the IAM solution as a part of GovStack are required to automate a variety of operations that sometimes utilize workflow-based approval steps. Detailed audit logs must be associated with each of these operations so that organizations can answer the following fundamental questions: | MUST | Both | Could be implemented |
|
6.2.15 Connectors | The IAM solution must provide a large range of connectors for both source and target applications out-of-the-box, The reason for this is that GovStack will be deployed in more than one country and in unknown applications environments and must be able to be integrated with many different common enterprise information systems and services both on premise and in the cloud in a simple and cost effective manner… for example: | MUST | build | Implemented | We are supporting all of platform required protocols of the systems we need to be integrated for a specific moment |
6.2.16 Access Management | Access management is an integral part of the required IAM solution. The Access Manager must provide a scalable, secure and consistent solution to implement policy based access for applications in hybrid cloud environments for both internal (employees), citizens (external) and 3rd parties (external) alike.
The Access Manager must provide the following tools to enable these objectives (see ensuing rows): | MUST | deploy | Implemented |
|
6.2.17 Web SSO | Web single-sign-on must be provided with support for SAML 2, oAuth 2, OpenIDConnect, OIDC, and a proxy to allow SSO to legacy applications. This enables web based applications to be easily configured for SSO without modification. | MUST | deploy | Implemented | Keycloak supports those standarts |
6.2.18 Adaptive Authentication | An adaptive authentication system as follows must be provided with the following features: | MUST | deploy | Could be implemented | authentication with identity provider or certificates supported for a moment |
6.2.19 Multi Factor Authentication (MFA) | Note:- see authentication too - but this is for MFA to target applications integration for the purpose of access management: SMS-based OTP | MUST | deploy | Could be implemented | Not supported |
6.2.20 Social Sign-on (as opposed to single-sign-on) | The Access Manager should allow social sign-on from social identity providers such as Google, Facebook and LinkedIn. Social registration significantly reduces the registration effort by allowing select attributes to be dynamically transferred from the social provider. This may or may not be used in practice but is a desired feature. | SHOULD | deploy | Not the same approach | Not enough trusted identity provider for government area |
6.2.21 RBAC Based Authorization | The IAM solution must provide a flexible RBAC-based authorization model to enforce security into applications through the Access Manager. The RBAC model must support inheritance as well as direct entitlements and provide the flexibility needed to implement complex real world requirements. The authorization service must be able to be used in conjunction with oAuth2 and the Access Gateway to enforce the authorization rules. | MUST | deploy | Implemented |
|
6.2.22 Session Management | The IAM solution must provide session management for issues like session timeout to reduce the exposure created by long running sessions. This includes API’s to extend expiring tokens etc. for application and user convenience. | MUST | deploy | Implemented |
|
6.2.23 Device Registration | The IAM solution must provide device registration such that only registered devices can be used to access services by policy. | MUST | deploy | Not applicable | Managing end-user devices is not a platform responsibility. The platform instance owner should manage this. |
6.2.24 Fine Grained Audit Logging | The IAM solution must provide fine grained audit logging by the Access Manager so that the explicit date, time, user and service access is logged. | MUST | deploy | Implemented |
|
6.2.25 Access Gateway | An access gateway is required in order to provide protected proxy gateway access to the web through reverse and front side web infrastructures such as Apache and Nginx web servers. This must provide the following functionality: | MUST | Both | Implemented |
|
6.2.26 Legacy SOA Security Features | The IAM suite must be able to implement a pure legacy SOA approach. A legacy SOA API with all required operations must be available to facilitate integrations with legacy SOAP/SOA systems. The IAM solution must provide SOA federation for controlling access to services in a legacy SOA environment using SAML, SAML 2 and WS-Security. The IAM solution must be able to enforce policies throughout SOA based services. RBAC and XACML support must be provided to allow the IAM solution to implement a flexible security model that supports the following: | MUST | deploy | Not the same approach | We are not supporting legacy SOAP endpoints for a moment |
6.2.27 Web Access Management | The Access Gateway must be able to provide coarse-grained authorization when protecting web applications in totality. Requests must be routed through a proxy, which applies authorization rules, and forwards the request to the underlying servers, providing the application. The model must be simple to deploy and easy to maintain. User identity must be checked and propagated through HTML header injections, HTTP query strings or HTTPS authentication headers to applications hidden behind a proxy server for the purposes of openness and compatibility. The native URL of these applications must be hidden from the public view (i.e. it is only exposed as a service name in a secure manner). | MUST | deploy | Implemented |
|
6.2.28 Single Sign On (SSO) | Each partner application, as well as internal applications and building blocks, may have their own set of security credentials and various authentication methods. Such applications may move in and out of security domains. | MUST | deploy | Implemented |
|
6.2.29 Federation | When GovStack is deployed it will need to be deployed with partners, suppliers and other organizations. For them to collaborate effectively, identity information needs to be propagated. The IAM solution must be able to manage the processes for federating users when a partner site comes on board or leaves. Federation capabilities must be provided by the IAM access manager solution. New cost recovery streams may be generated for GovStack users through enablement of trusted partnerships where authentication and authorization is carried out over federated business networks. | MUST | Both | Implemented | We are using only central credentials storage so all of the credentials federated from day 0 |
6.2.30 Security Token Service (STS) | STS is a system role defined by the WS-Trust specification. A Web Service Client interacts with the STS to request a security token for use in SOAP messages. In addition, a Web Service Provider interacts with an STS to validate security tokens that arrive in a SOAP message. An STS arbitrates between different security token formats. | MUST | deploy | Not the same approach | No SOAP support |
6.2.31 Role and Attribute Based Access Control (RBAC/ABAC) | The IAM solutions Access Manager must manage Groups, Roles, Permissions and Resources supporting both RBAC and ABAC. Groups are generally used to model organizational structure whereas Roles are used to model a person’s function within the enterprise. In RBAC, a subject is given one or more roles depending on the subject’s job. Relationships between Users, Groups, Roles, Resources | MUST | deploy | Implemented | We are using RBAC, but we have mechanism in place for implementing ABAC |
6.2.32 High Availability | The solution provided and any associated components MUST be highly available and utilize clustering technology in order to provide a minimum of 24x7x365 service with 99.99% availability (AKA 4 9’s). | MUST | deploy | Could be implemented |
|
6.2.33 Open Source Offering | The offered solution MUST be based fully on open source components. The vendor may offer subscriptions for support so long as the offered solution does not require those subscriptions in order to deliver the core functionality specified in this document. | MUST | build | Implemented |
|
6.3 Service APIs |
|
|
|
|
|
All APIs will be defined using the OpenAPI (Swagger) standard. |
|
|
| Implemented |
|
IAM Suite API: An example of such a REST API is provided with the OpenIAM suite specification |
|
|
|
|
|
|
|
| Implemented |
| |
|
|
| Not the same approach |
| |
LDAP API: A description of the standard REST LDAP API provided by the open source 389 Directory Server here: . |
|
|
| Not the same approach | We are not providing REST LDAP API |
6.4 Workflows |
|
|
|
|
|
6.4.1 Identity and Access Sequences |
|
|
|
|
|
6.4.1.1 User authentication and authorization |
|
|
| Implemented |
|
6.4.1.2 Self-registration via phone number or email |
|
|
| Not the same approach | No self-registration possibility |
6.4.1.3 Self-registration via foundational ID |
|
|
| Implemented |
|
6.4.1.4 Self-deprovisioning via foundational ID |
|
|
| Not the same approach | No self-registration possibility |
6.4.1.5 Deprovisioning via government official |
|
|
| Not the same approach | No deprovisioning |
6.4.2 Standards |
|
|
|
| No specific requirements in security specifications regarding standards. Each BB defines its means to be followed during implementation. |
6.4.3 Interaction with Other Building Blocks | The security building block predominantly deals with the cross-cutting security concerns of each other building block and defines the basis for the implementation of solutions to address these concerns. The only interaction required is for API Management and Gateway services. These interactions are depicted and documented in Architecture Blueprint and Functional Requirements (see Ref 1). |
|
|
| The interaction is defined in an architecture blueprint and the functional requirements of each BB. So not in the scope of security specification review. |