Creating your first project
oak9 automatically collects and analyzes infrastructure code that for any vulnerabilities before you deploy. Creating your project is the first step.

The basics

Projects are an application or workload that you want to secure in the cloud.
In modern cloud native architectures there are hundreds of cloud native features and services that are interacting with each other via access policies, events, network communications, etc. These services are often developed by different teams or business units each with their own life cycles. This makes it very difficult to infer boundaries of an application or workload. A project is a flexible way for an organization to help define these often-blurred boundaries and enable oak9 to dynamically apply specific security requirements and standards that the organization is looking to meet.
That said, creating a project is simple - it only takes answering 5 questions.

Creating a project

Hit the big '+ New Project' button in your top menu. Give it a name and answer 5 questions.

5 Project Questions

Deployment Model

Tell us how you application architecture is built and deployed
  • Public cloud (i.e. Aws, Azure)
    • Deploying to a public cloud environment means the infrastructure and services being utilized are shared broadly
  • Private cloud (i.e. on prem or data centers)
    • Deploying to a private cloud environment means the infrastructure and services being utilized are not shared outside the organization.
  • Hybrid - split across the public cloud and data centers
    • These application components are being deployed across a combination of public, private, or on-premise environments.

Data Sensitivity

Data sensitivity relates to the extent to which access to data should be limited and the potential risk associated with unauthorized access to data. Data can be classified along a spectrum from public to business sensitive.
Public data is any information that is in the public domain, the unauthorized access to which poses little or no risk. At the other end of the spectrum is business sensitive data, or data that must be strictly protected from access by outside and/or unauthorized parties. An example of sensitive data is Personally Identifiable Information, or PII. PII data permits the identity of an individual to be directly or indirectly discovered and includes home address, social security number, financial or medical records.
Business sensitive data includes intellectual property, trade secrets, and financial and customer data. If the project created must conform to data protection standards or regulations such as HIPPA, PCI-DSS, or GDPR, refer to those standards to discern the level of sensitivity, and therefore data protection, that must be configured into the project.
As noted, the level of data sensitivity can be chosen for the project by referring to the data protection standard to which the project must conform. Choose public if the data is generally available in the public domain. Choose business sensitive if access to the data must be strictly limited to authorized users, or categories of authorized users. Choose a setting between those two points depending upon the extent to which access to the data should be limited.

Business Impact

Business Impact addresses the Impact that a loss/incident could have on your organization
  • The Impact can be financial loss, disruption to business operations or systems, legal, regulatory, reputational, or related to safety
  • Select the business impact that would apply if the confidentiality of the platform is compromised_._
High: Catastrophic or significant impact to the business
Medium: Moderate impact to the business
Low: Low impact to the business
Only one impact level can be selected for a project

End Users

End Users addresses the type of users that will be interacting with the oak9 platform
  • Select the type(s) of end-users.
    • Workforce
    • Consumers
    • Business Partners
Select all end-user types that apply

Compliance Framework

oak9 incorporates your compliance and regulatory requirements to provide security design guidance for your application. We have out-of-the box support for a number of industry standards, compliance frameworks and regulatory requirements that you want your application to adhere to.\
Selecting your compliance frameworks is an important step in ensuring that oak9 understands the business context of your application. If your organization provides services within a unique regulatory environment, this will drive unique security requirements that oak9 will ensure your application addresses. Some compliance frameworks have different levels of rigor (e.g., NIST SP 800-53 has High, Medium and Low levels; HITRUST has increasing levels of rigor from 1-3). oak9 will ensure that your application architecture aligns with the security requirements of a given industry standard or compliance framework to satisfy the level of security rigor required.
Another advantage of selecting the applicable compliance frameworks is that oak9 will provide visibility into how your application architecture is fulfilling your compliance frameworks. Design gaps will be mapped to selected compliance frameworks along with oak9’s technical security requirements. Oak9 can generate reports for auditors and compliance professionals to provide real time compliance and security information about your application.
Selecting “Not Sure” under compliance frameworks will skip the validation of regulation-specific requirements but will still assess for design gaps and validate security best practices. You can add or change the compliance frameworks at any time by going to your project’s page and clicking the edit button near compliance frameworks.

Compliance frameworks supported by oak9:

Compliance Framework
Summary
HITRUST CSF
CSF or "Common Security Framework", the HITRUST CSF is a prescriptive set of controls that meet the requirements of multiple regulations and standards. It leverages internationally accepted standards and regulations such as GDPR, ISO, NIST, PCI, and HIPAA to create a comprehensive set of baseline security and privacy controls.
NIST SP 800-53 r4
This publication provides a catalog of security and privacy controls for federal information systems. The controls address a diverse set of security and privacy requirements across the federal government and critical infrastructure, derived from legislation, executive orders, policies, directives, regulations, standards, and/or mission/business needs.
HIPAA/HITECH
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) mandates industry-wide standards for health care information on electronic billing and other processes and requires the protection and confidential handling of protected health information. The HITECH Act, published in 2013, made several changes to HIPAA and introduced new requirements for HIPAA-covered entities with notable changes for business associates.
GDPR
The General Data Protection Regulation (GDPR) is a legal framework that sets guidelines for the collection and processing of personal information from individuals who live in the European Union. Since the Regulation applies regardless of where websites are based, it must be implemented by all sites that have European visitors, even if they don't specifically market goods or services to EU residents.
PCI DSS v3.2.1
The Payment Card Industry Data Security Standard is an information security standard for organizations that handle branded credit cards from the major card providers. The standard was created to increase controls around cardholder data to reduce credit card fraud.
ISO 27001
ISO 27001 is an international standard that helps organizations manage the security of their information assets. It provides a management framework for implementing an information security management system to ensure the confidentiality, integrity, and availability of all corporate data such as financial information, intellectual property, employee details or information managed by third parties.