Product Security Program

Product Security Group (ProSeG) Dec 2021

1.INTRODUCTION

A.Purpose of this Product Security Program

AINQA develops enterprise healthcare software, using multiple technologies and development methodologies with its employees across multiple geographies. AINQA is committed building software that is secure and robust against cyberattacks.

This document provides an overview of AINQA's product security program comprises various security activities and how security is built into every step of the Software Development Life Cycle (SDLC).

This document intended to provide AINQA employees in general particularly for the customer facing employees who can provide assurance on the quality of AINQA products by providing details into the AINQA product security initiatives. The document also set expectation for various technical staffs that involve in various stages of SDLC which ranges from Developers, Business Analysts, Quality Managers, Project Managers to Penetration Testers.

B.Mission and Goal

The mission of the AINQA Security Program is to establish, oversee and carry out plans of action for any vulnerability that potentially threatens the confidentiality, integrity or availability of AINQA’s products and services. To achieve the mission, AINQA Product Security Group have goals to embed security and reliability in everything we build and deliver.

C.Scope of the Program

The Product Security Program is developed for all the enterprise and SaaS software solutions that AINQA develops. Each AINQA product undergoes through security reviews and security testing prior to release. AINQA Product Security Program uses criteria such as the OWASP Top Ten and NIST Secure Software Development Framework to assess the security of AINQA products. The overall program is meant to support people in the AINQA organization.

D. References

• National Vulnerability Database (NVD) – NIST
• Open Web Application Security Project® (OWASP)
• VMWare Container Security
• NIST 800-190: Application Container Security Guide

E.Responsibility of Product Security Program

Since inception of the AINQA Product Security Group, various software security and quality measures are being implemented and explored thus making a product release more stringent and secured. The Product Security Group at AINQA is responsible for upholding AINQA's corporate standards of quality, especially as those standards relate to defining, evangelizing, and measuring all aspects of security within all product line development lifecycles. The group is in the midst of developing governing policy, metrics, and guidelines for ensuring that all AINQA products meet security standards.

At AINQA, product security is an integral part of product architecture, development, and quality. It is more like a journey than a destination therefore it is a continuous process of refining product security by adapting to new technologies and tools, growing in tandem with sophisticated threat landscapes.

F.AINQA Product Security Group (ProSeG)

AINQA being a startup company, the dedicated roles for security are limited. As such, security will be a shared responsibility. The only position that formalized is Information Security Manager (ISM) that reports to CTO. At the current moment in the shared responsibility model, security champions across the department particularly in technology is identified and performing security roles as an additional role. As the organization evolve and grow more dedicated roles to be introduced fitting in the various sub sections of security.

The purpose of the group is to formally establish a security interest group within AINQA that comprise of various people from different area of technology. The group will play advisory and security operations role when comes to matters related with cyber security in AINQA. The high-level Group organizational chart is presented in Figure 1 below. The Figure 2 in the next page depicts the AINQA Product Security Group (in blue shade) from the overall Enterprise Security. The Enterprise Security Framework will be the ultimate end-state that AINQA will reach once the security processes are matured.

Figure 1: AINQA Product Security Group Org Chart

Shared Responsibility (Red / Blue Team | AINQA CERT)

Figure 2: AINQA Enterprise Security Framework (adapted from the Microsoft Security Best Practices)

2. Secure Software Development Life Cycle

Figure 3: Secure SDLC

AINQA prioritize security throughout the Secure SDLC of a product as per in the Figure 3. This document provides high level details on the various security considerations when developing a solution. The SSDLC starts from initial ideation and design through development, testing, release and operation. To ensure this security considerations are adhered too throughout all the development lifecycles, strong processes and tools are put in place to ensure developers are comply with the security requirements.

Among the common industry best practices followed are (not limited to):

• Defense-in-depth
• Separation of privilege
• Failing securely
• Least privilege
• Threat modelling (to be introduced)
• Attack surface analysis (to be introduced)

All the techniques mentioned are recommended to identify in the early stage of application conceptions. For this, writing security requirements alongside functional requirements and performing an architecture risk analysis during the design phase of the SDLC is a must. Business Analyst made aware of this and required to produce a Security Requirements section in their SRS document. AINQA developers are/to be trained to use a "shift-left" approach to security. This is to ensure application security is taken consideration at the earliest stages in the development lifecycle. This method not only reduce the risk but also the cost of re-developing application at later stage.

3. Security Testing for Ainqa Products

Depending on its requirement, each AINQA product and services will go through Vulnerability Assessment and Penetration Test (VAPT). At this moment, the Product Quality team is performing this task. At later stage (Est in 6 months), AINQA will introduce more formalized Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST).

SAST is to be performed on AINQA products on a continuous basis to ensure secure code is delivered. DAST is performed using industry-leading testing tools to analyze applications in their dynamic, running state during the testing phase of the product development lifecycle.

Manual penetration testing of AINQA products is performed by the internal penetration-testing team and if needed external penetration-testing firms, or both. The outcome of the test will be analyzed and categorized based on the Common Vulnerability Scoring System (CVSS v3) and guided by the OWASP Top 10 list. Anything identified as high risk, the development team mitigates the vulnerabilities before releasing it to production. For, vulnerabilities identified as medium risk, an action plan is required ensuring the gap is closed within a short period of time. While a risk is being mitigated, a Risk Assessment is performed and communicated with the key stakeholders ensuring they aware the risk during the interim period.

4. External Software & Dependencies

Being a strong open-source advocate, AINQA uses many open-source libraries, tools and external software. Though it’s easier to create software but it means also we do not have sufficient control over the code the developers working on. Third party Dependencies / libraries has its own set of risk and setbacks and it also listed as one of the top 10 in the OWASP list. Realizing this at AINQA, stringent security measures are taken ensuring only secured and reliable source of libraries are used in the development of AINQA products. The followings are to be performed:

• Actively keeping track of dependency versions and potential vulnerabilities.
• Ensuring developers understand and do a pre-screening of dependency files before committing in their code
• Perform vulnerability scanning using industry-leading tools
• For each component / library, a scan against National Vulnerability Database (NIST) to be performed
• For third-party commercial software, a manual review of security reports is performed

All the above drove AINQA Product Security Group to establish Software Composition Analysis (SCA) activities, where more structured approach will be performed in SCA. SCA is the process of analyzing source code to identify open-source software in the code base, and to determine applicable licenses. The process also enables the evaluation of any security risks resulting from discovered vulnerabilities. The SCA will produce a formalized vulnerabilities list for tracking and risk mitigation purposes. SCA will produce:

• Software Bill of Materials (SBOM): A list of all discovered software components with their corresponding licenses.
• Security Vulnerabilities: A list of known security vulnerabilities discovered in the codebase. It corresponds to specific software components, including severity classification and recommendations for mitigation.
• Project Health Metrics: Specific metrics related to the health of open-source projects discovered in the body of code analyzed.

SCA works on an “inventory, analyze, and control” framework to give AINQA development teams a full view of their open-source usage and guidance on how to resolve any issues.

5. Malware Prevention

AINQA Product Security Group through the QA team performs the followings to reduce the risk of introducing malicious code or malware into AINQA products:

• Before any source code check-in and product builds, peer code reviews are encouraged.
• Production environment will go through stringent AINQA Baseline security checklist ensuring proper controls are in place. These controls include endpoint protection which is deployed on all the servers.
• A thorough scanning for malware and sensitive information is performed on containers before a release.
• Developers awareness program ensuring security mindset throughout every phases of development

6. Manual Application Penetration Testing

During the major release of each AINQA product, a manual application penetration testing is performed independently by the Quality Team. The team uses mixture of various open-source tools to assess the security posture of a product. The penetration test comprises system-level tests, web application, API tests, binary scanning and network scanning tests that go through the list of OWASP Top 10 and provide recommendation. Additionally, if needed AINQA engages third party to perform the test for additional assurance.

7. Container Security

At the core of AINQA development framework is the containerization where almost all the development work in AINQA relies on Microservices architecture. Though there are many benefits of this type of architecture, it is also introducing broader surface attack for adversaries promoting lateral movement and privilege escalation. Therefore, the Product Security Group identified container security is the topmost priority. Hence, various controls are being introduced in stages ensuring the whole spectrum of container security is covered.

Container security can be defined as the holistic application of processes, tools, and other relevant resources, with the aim of providing strong information security for any container-based system or workload. To ensure the container security is paid attention, the Security Group is introducing Microservices Security in the AINQA Baseline Security Checklist V2.0. Among the controls to be considered are:

• Securing code and its dependencies
• Starting with minimal secured base images from a trusted source
• Checking images for vulnerabilities early and often
• Scanning container configurations using SAST tools
• Reported vulnerabilities are fixed and the fixes are verified within the SDLC.
• Considering the whole stack i.e., from code, CI/CD, Registry, Cloud, Host, Kernel
• Ensuring cloud providers adhered to the best practices

8. Cryptography

AINQA is committed in ensuring the data particularly Protected Health Information (PHI) is guarded whether it is at rest or in transit. The development team follows industry best practices and NIST-recommended guidelines for secure cryptography. The enterprise cryptography policy requires the use of:

• AES-256-bit encryption or RSA with OAEP padding for data at rest
• PBKDF2 with HMAC SHA-512 or PBKDF2 with HMAC SHA-256 for end-user credentials storage
• TLSv1.2 and later for data in transit

The protection of healthcare records with right technologies progressively whether it is SaaS or on-premises solutions is paramount for AINQA. Hence the Product security Group always on-lookout for latest encryption technologies.

9. Security Response & Communication

In any publicly disclosed vulnerabilities or zero-day attacks that involve third party software or open-source components that impact AINQA product line, a process is being drafted to handle such situations. The Product Security Group will take the necessary actions and orchestrates activities by assessing the risk and mitigate it as earliest possible working with all the stake holders. A proper communication plan is devised and followed ensuring the situation is handled tactfully.

The Product Security Group is devising a formal escalation process for vulnerability disclosures regardless of their source (developers, customer, internal QA team, or others). Based on the severity of the vulnerability, each disclosed vulnerability is directed to the senior management of the relevant product's development team, remediated by that product development team, and communicated to affected customers by the product support team.

A Product Security Bulletin & Security Updates page is planned to provide timely security-related information and vulnerability information for AINQA products in near future once the product lines commercialized.

Additionally, the Product Security Group is formally establishing a Computer Emergency Response Team (AINQA-Cert), to handle any security related incidents whether it is related to corporate security or product security.