Level Access Security Policy

 

General

LEVEL ACCESS has a deep and abiding commitment to security. LEVEL ACCESS’s approach for system and network configuration is based on a combination of the principle of least privilege and focused application, server and network hardening. Systems are deployed using a standard virtual machine image that is extensively locked down to only allow access to the specific ports that are needed on the machine. This ensures that LEVEL ACCESS can rapidly deploy a fully locked-down environment that is configured in a standardized fashion. This process is automated as part of the Amazon Web Services (AWS) environment to minimize any human configuration error issues. LEVEL ACCESS actively patches all production system images and open source libraries used in the system. This ensures that known security issues are rapidly patched and addressed in the system.

All network transfers are performed over encrypted channels. All production web servers are behind network level firewalls that only allow access via TLS. Access to LEVEL ACCESS’s web application is managed via strong username and password protection. All data in the system is validated by the application to ensure that only expected data is stored. LEVEL ACCESS uses an application architecture that provides secure separation between various system components. This validates that all operations are provided at a valid level of privilege when executed on the target object.

Policy Review and Updates

This policy is reviewed, updated, and validated on a quarterly basis. More frequent updates occur on an as-needed basis in response to any key changes in the information security environment that must be addressed to ensure the robustness of the policy. All changes are reviewed and approved by both the staff information security personnel and senior management, including the office of the CEO.

Client Specific Information Security Requirements

LEVEL ACCESS often works with clients to ensure deployments and engagements meet client specific information security requirements. As needed, LEVEL ACCESS can complete a security checklist or questionnaire to substantiate conformance.

Incident Reporting

LEVEL ACCESS utilizes its standard ticket logging process to document any issues relating to security incidents and manage their resolution. Breach issues are tracked as P1 issues in our support process. As P1 issues, response times are within 60 minutes during our standard support hours, as indicated in our SLA.

Software Security Policy

LEVEL ACCESS follows a holistic approach to application security characterized by the development of a comprehensive security coding framework that identifies threats and risks in the early stages of developing a product, provides for peer review of code during the development phase and performs security testing of applications during the QA phase. This approach incorporates the best practices, coding, and testing guidelines from independent organizations such as Open Web Application Security Project (OWASP), Web Application Security Consortium (WASC), and also vendor-specific concepts including Microsoft STRIDE and Application Security Framework (ASF). LEVEL ACCESS’s primary focus is on the OWASP Application Security Verification Standards and utilizing those as a baseline for key application level security validation.

Secure Software Development Lifecycle

LEVEL ACCESS has a secure software development lifecycle (SSDLC) policy that is actively reviewed and maintained. The policy is communicated to all members of the LEVEL ACCESS Scrum Team formally during onboarding and through LEVEL ACCESS’s internal policy documents, which outline the expected steps to be taken at each phase of the SSDLC. The LEVEL ACCESS Scrum Team is made of Business Analysts, UI Designers, Software Engineers, and Quality Assurance Engineers. This policy has been approved by management, and is owned and maintained by the Software Security Lead. Each member of the team that is responsible for the following phase is responsible for ensuring all items in the previous phase was completed in compliance with the SSDLC policy.

The LEVEL ACCESS Scrum Team reviews the lifecycle policy on a quarterly basis in line with the policy review, update, and validation approach defined in the Policy Review and Updates section of this document. In addition, more formal review and updates occur as needed based on the results of external security audits and penetration testing.

Feature and User Story Review

LEVEL ACCESS performs ongoing architecture and development requirements reviews at the level of Features and User Story definition during the ongoing Scrum development process.  This review is completed by a member of the LEVEL ACCESS Software Security Group prior to the Feature or User Story moving forward in the Scrum process.  This requires that any Feature or User Stories that have a potential security impact properly define and address security concerns prior to development.  Further this ensures that the Feature and User Story is tested for security considerations as part of the standard QA and acceptance process versus out of process and solely as part of a security review.  This explicit review and signoff process occurs as part of Jira – LEVEL ACCESS’s change control management system.

Secure Code Review

LEVEL ACCESS performs ongoing secure code reviews as part of the scrum process. Developers work together to review each other’s code as a part of the SDLC. All code is reviewed prior to testing to ensure that secure coding practices are employed.

LEVEL ACCESS employs Veracode’s Source Code Analyzer to enhance and provided secondary application scanning in addition to internal code reviews. Application scanning happens on an ongoing basis as part of LEVEL ACCESS’s standard SSDLC during the QA process and “Definition of Done” for a story.  In addition, the full application is reviewed and scanned as part of every major release.  The product owner is required to sign-off that these reviews have occurred.

Application Vulnerability Audit

LEVEL ACCESS has a third party perform a structured application vulnerability audit on an annual basis. All vulnerabilities are (i) flagged for remediation as user stories in LEVEL ACCESS’s ongoing Scrum development process, and (ii) communicated to developers to allow them to incorporate this information into the coding practices and reviews. The code level resolution of vulnerabilities is escalated based on severity, and can range from being fixed and patched immediately to being resolved in the next release.  In addition, the full vulnerability report is formally reviewed with the full development team as part of the retrospective for each release.  The goal of this is to ensure ongoing review and improvement with respect to security issues occur across all known security issues versus those specific to each developer.

Input Validation

All AMP (Accessibility Management Platform) system inputs are validated for a variety of requirements including, but not limited to, code, JavaScript or SQL commands. Data integrity checks are performed at both the browser level through JavaScript and at the application level through variable screening. Validation at both levels includes input size, formatting, and encoding, among other form specific parameters.

SQL Parameter Validation

All parameters are screened and validated on the server side prior to inclusion in any database update code. Database access is abstracted through a typed, data object layer, avoiding direct insertion of variable values into the database. In addition, AMP uses prepared SQL statements to drastically limit the potential for attackers to insert any SQL code via user-submitted variables.

Edge Case Validation

As part of user story definition, implementation and testing edge cases for all user interface components and variables are considered and tested.   User story definition includes allowable ranges and validation requirements for all posted variables.   Implementation requires that these ranges be constrained in the user interface side (prior to submission) and validated when the variables are posted to the server.   Finally, the quality assurance process validates that these are the sole, allowable ranges for the variables.  This includes testing both formatted inputs that are out of range as well as a variety of fuzz variable submissions.  Fuzz variable submissions include random values, hexadecimal and binary sequences, random, dangerous bits of SQL code, command line inputs and all other types of nasty inputs that an attacker might enter into the application.

System Updates

AMP is released twice a quarter with major versions numbered based on the year and minor versions numbered in linear progression from one to eight. Upgrades are provided on an all or nothing basis and generally do not allow specific feature upgrades to be carved out of the upgrade process. Information regarding new releases is distributed to all clients via e-mail, in system banner and formal announcements on LEVEL ACCESS’s web site and social media channels. This includes an updated AMP Overview document and a “What’s New?” document for the AMP release.

For SaaS deployments, clients are upgraded to all new features in the release automatically and no client action is required. For client dedicated instances and on-premises deployments, clients can control version upgrades and timing. For such systems, the LEVEL ACCESS project manager will work directly with the client main point(s) of contact to schedule the upgrade to occur on an agreed-upon date and time.

System Maintenance

Planned downtime for maintenance occurs twice a quarter, coinciding with AMP releases. This maintenance rarely results in downtime of more than one hour for our hosted clients, with downtime occurring outside of operating business hours. During planned periods of outage, a system message will be placed on the client’s AMP instance displaying the time and date of the planned outage. Notice and warning of the forthcoming upgrade is provided at least five (5) days prior to the upgrade.

System Update Signing

LEVEL ACCESS can provide a one-time code signature for any system updates on request to ensure the integrity of the system update being provided to the client. This is only applicable to clients utilizing on-premises deployments of any of the Services.

Standards Compliance

LEVEL ACCESS does not currently carry any formal security certifications and utilizes a principally in-house approach to security with key vendors performing application and network level vulnerability and penetration testing. LEVEL ACCESS’s hosting provider, Amazon Web Services, does, however, carry a variety of standards and certifications. For more information on that please consult the AWS Compliance Page.

Regulatory Compliance

Regulatory compliance issues are managed by LEVEL ACCESS’s operations team (general issues) and product team (AMP specific issues). That noted, the following general compliance requirements are noted:

• SOX – LEVEL ACCESS is not a publicly traded company and, as such, is not required to comply with Sarbanes-Oxy.
• PCI – LEVEL ACCESS does not accept credit card transaction over the Internet and, as a result, does not have to be PCI compliant. With that said, all transmitted data is sent over SSL using 256-bit encryption.
• GLBA – LEVEL ACCESS is not a financial institution and, as such, is not required to comply with GLBA.
• FFIEC – LEVEL ACCESS is not a financial institution and, as such, is not required to comply with FFIEC.
• HIPAA– LEVEL ACCESS is not a health care provider and, as such, is not required to comply with HIPAA.

Software Security Group

LEVEL ACCESS’s Software Security Group includes two senior software developers and the product owners for all LEVEL ACCESS products. The senior software developers work throughout the scrum process as security subject matter experts. In addition, they work with third party validation providers on an ongoing basis to incorporate the findings of security audits and testing into this policy, LEVEL ACCESS’s SDLC, and to ensure secure coding and testing practices occur in practice. Product Owners for production systems are ultimately responsible for their security and for ensuring proper diligence has been given to security throughout the SDLC.

The Software Security Group interfaces with the Incident Response group via LEVEL ACCESS’s standard support and ticketing process. As with in-process testing and third-party security audits and testing, all vulnerabilities are communicated to developers to allow them to incorporate this information into the coding practices and reviews. The code-level resolution of vulnerabilities is escalated based on severity and can range from being fixed and patched immediately to being resolved in the next release.

Updates and Patches

Updates and patches to network, operating system, server, and application level systems and libraries occurs on a twice a quarter basis as part of the standard release process. In addition, hotfixes, live patches, and updates are applied on a continuous basis as needed and dictated by the relatively severity of the issue and its impact on the end user experience. If critical vulnerabilities are discovered, they are fast tracked and patched within a day. Security issues are generally patched immediately and made available to clients on the same basis. Operating system issues and other third party software issues that are low severity and non-security related are patched as part of the standard release process.

Members of LEVEL ACCESS’s Software Security Group monitor the National Vulnerability Database against LEVEL ACCESS’s current application and system stack. This allows us to keep abreast of new vulnerabilities that we need to patch against prior to those patches becoming available in LEVEL ACCESS’s patch management system or process.

Antivirus

LEVEL ACCESS utilizes ESET Endpoint Antivirus for desktop antivirus. LEVEL ACCESS antivirus infrastructure also provides support for monitoring and scanning for malicious code. This, combined with basic security training and policies, forms LEVEL ACCESS’s approach to limiting malicious code execution.

LEVEL ACCESS’s server environment is hardened Linux and does not general utilize antivirus software, but focuses on active patching for all core services.

Development System Segregation

All development, test, and production systems are separate. They operate on different network systems and provide different levels of access.

Incident Handling

Security incidents are logged and handled using an expedited version of LEVEL ACCESS’s support process. Any security incident that could potentially impact client data will be communicated to the client immediately, and a solution joint will be determined with the client.

Change Control Process

LEVEL ACCESS utilizes the Scrum SDLC process and manages software configuration and change management accordingly. LEVEL ACCESS utilizes Jira as a system of reference for changes to the software.

Release Process

AMP receives periodic updates based on on-going development. Formal releases occur on a monthly basis. Clients may opt into different release schedules, with most enterprise non-SaaS clients opting into quarterly releases.

Early Access

As needed and defined on a per client basis, LEVEL ACCESS can provide access to upcoming releases of AMP on staging servers for the purpose of reviewing upcoming releases.

Upgrade Notice

LEVEL ACCESS provides active communication in advance of software upgrades and patches. This is provided via e-mail announcement and through in-system banner announcing the updates.

Access Control

Network Level

All networks are managed, controlled, and accessed from a limited set of IP range restricted access that requires login to the LEVEL ACCESS internal network prior to accessing any production systems. Dial-up, wireless, and other non-IP restricted access to production environments is not allowed and is explicitly restricted and enforced at the network level by AWS.

IP Access Restrictions

The system supports IP access restriction at both the network and port level, but does not support it at the server or application level. IP based access restrictions can be configured on a per client basis for client specific instances under Enterprise class subscriptions. These restrictions can be applied at IP and port level.

Server Level

Server level access is provided via a combination of user authentication and user specific certificates that provide support for logging in to production systems. Sever level access is layered on top of Network Level access restrictions with access being required at both levels. All server level access is encrypted with terminal access solely via SSH and file transfer access solely via SCP.

Application Level

AMP utilizes unique username and passwords to provide access control. This can be overridden on a per client basis and can utilize the client-specific SSO system instead.

Once a user is authenticated, AMP provides significant controls on who can access reports and how the report information can be distributed. AMP reports can be easily distributed to an unlimited number of users within an organization and to duly authorized third parties via e-mail. Viewers are provided access to the report via a streamlined, simplified AMP interface that quickly routes them to the needed information in the system.

Administrators can create flexible report groupings through the use of projects, specific report access lists, and by designating specific, individually authorized users. This framework provides for the easy management of the relationship between report viewers and testing teams while allowing administrators to have precise control over who can access reports.

More detail on application report and access is provided in the User Roles and Permissions section of this document.

Least Privilege Philosophy

All system access and execution – particularly server and operating system access – is provided on a least-privilege and need-to-know basis. Privileges for execution must generally be elevated from base login privileges for execution.

Mobile and Remote Access

Mobile, telecommuting, and remote access to AMP are supported insofar as the system can be access via the web. Currently, LEVEL ACCESS does not limit device access the application, server, or network level, but can limit these at the level of specific clients via server configurations.

Single Sign On (SSO) and Federated Identity Management Options

LEVEL ACCESS provides for a variety of SSO and federated authentication approaches that allow specific clients to integrate AMP user authentication with internal user management and authentication system. Currently, there are customizable modules for SAML, Shibboleth, LDAP, and Active Directory integration. Federated SSO authentication is something that is generally customizable on a per-client basis. This integration can be configured to automatically create user accounts based on a valid SSO authentication and user information released from the client’s Identity Provider. LEVEL ACCESS sees this approach as the standard go-forward model for enterprise user authentication.

Password Policy

LEVEL ACCESS has a standard system password policy that provides for basic controls on passwords for the system. This system is configurable and can be extended on a per client basis to conform to client specific password policies. In general, this is implemented as part of deploying a SSO integration with the specific client.

Password Encryption

All passwords are one-way hashed and cannot be decrypted or recovered. No version of the password other than the hash is ever stored, and passwords are never stored in clear text.

Invalid Password Message

When an invalid password is entered, the error message will indicate if the user has entered an invalid password; however, this can be configured on a per client basis.

Password Expiration

User passwords do not expire by default, but the exact security policy, password maintenance policies, and credentials deployment approach can be modified and extended on a per client basis.

Login Failure

AMP limits users to six (6) consecutive login attempts, after which the user account is deactivated and must be reactivated. The reactivation process requires access to the owning e-mail account of the relevant account and can be accomplished automatically via e-mail after five minutes since the last failed login attempt.

Two Factor Authentication

LEVEL ACCESS does not support two factor authentication out of the box, but does provide support for two factor authentication via support from the client’s SSO implementation and on a per client basis for specific machine access. LEVEL ACCESS provides for a variety of SSO and federated authentication approaches that allow specific clients to integrate AMP user authentication with internal user management and authentication system. LEVEL ACCESS sees this approach as the standard go-forward model for enterprise user authentication.

User Roles and Permissions

AMP provides for a variety of different user types within the system that define various user scenarios for accessing AMP. This is provided in addition to Access Control Lists (ACL) for systems and reports to determine what content and functionality any given user has access to in the system. AMP currently supports the following user types:

• Viewer – Viewer users can access the system and view reports that they are explicitly given access to. In general, Viewer type accounts should be provided only to users that need to access system and report content, but who do not need to be able to address any of the issues associated with a report or be able to perform an audit.
• Evaluator – The user is evaluating the system and has limited access to all the features of AMP. This user type is set automatically for any user that does not have a current, valid license.
• Standard User – This user is a fully licensed user of AMP. This means that the user has access to AMP, and can use all the AMP features. The user does not have access to any administration features or settings. This user type is set automatically for any user that has a valid license and is not an Organization Administrator or System Administrator.
• Organization Administrator – This user is an administrator for an entire organization. They have the ability to access a variety of different organization settings, which include the Organization Testing Control settings. They can create, remove, edit and delete organization members, create Projects, AMP Tests, and modify all reports within an organization. They are capable of performing any activities that are restricted to their organization.
• System Administrator – System Administrators are LEVEL ACCESS employees, partners or AMP instance Administrators. They have full access to modify all system content, including best practices, test definitions, and standard definitions. They can access and modify all organizations in AMP and perform all the organization administration tasks available to Organization Administrators.

AMP’s navigation structure uses a system of progressive disclosure that ensures that for any given page, a user only has access to links that he or she can act on. This allows for a unified look at data that provides a user access to all those functions that he or she can act on and restricts action for any disallowed actions.

Secondary System Access

Absent specific integrations with other tools, AMP does not interact with other systems in an automated fashion. The one exception to this is the testing spider, which accesses web content as directed via HTTP or HTTPS.

User Specific IP Logging

For each login attempt, AMP logs the specific IP address that is used to attempt the login. If AMP detects a user login from multiple different browsers for multiple different IP addresses, this information can be used to determine if an account may be compromised, if it is being used in a fashion that does not conform to LEVEL ACCESS’s Master Subscription Agreement or the then-in-place governing agreement for the use of the Services specific to the client.

Default Password Changes

All default network, operating system, and application passwords are required to be changed prior to deployment of any systems and before account access is fully permitted.

Session Timeout

Default time for sessions to time out is two (2) weeks, but this can be configured on a per client basis. As noted in the General section of this document, AMP tends to focus on ease of access to information, and LEVEL ACCESS has actively chosen to provide longer user timeouts.

Account Creation

AMP allows organization administrators to manually create user accounts through the web administration tool. The accounts utilize a standard username and password model with account credentials stored internally by the application. Generally, account usernames are set to a user’s e-mail address and default account passwords are provided via e-mail and sent directly to the end users. Users can then modify and update the passwords as needed. As noted the exact security policy, password maintenance policies and credentials deployment approach can be modified and extended on a per-client basis.

Account Reset

Account reset is managed based on a documented process that requires the reset requester to have control of the requesting parties e-mail account. This can be extended or eliminated entirely via integration with client specific SSO system.

In general, if an account is locked out, an administrator can access the user’s account and initiate a password reset. This will result in the system notifying the user they have a new password which they can use to log in and unlock the account.

Concurrent Use

Concurrent use of a single user account from multiple devices or browsers is allowed as long as it conforms to the terms of use defined in LEVEL ACCESS’s then current Master Subscription Agreement or relevant client-specific use agreement.

Desktop Password Policy

LEVEL ACCESS’s policy is that all employees must have a password that conforms to our network password policy. This password expires annually and must set by the user to a new password that is not a variant of the prior password. The LEVEL ACCESS Network Password Policy is as follows:

• Passwords must not contain the user’s entire username value or entire Full Name value. Both checks are not case sensitive:
  • The username is checked in its entirety only to determine whether it is part of the password. If the username is less than three characters long, this check is skipped.
  • The Full Name is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the Full Name is split and all parsed sections (tokens) are confirmed not to be included in the password. Tokens that are less than three characters in length are ignored, and substrings of the tokens are not checked. For example, the name “Erin M. Hagens” is split into three tokens: “Erin,” “M,” and “Hagens.” Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included either “erin” or “hagens” as a substring anywhere in the password.
• Passwords must contain characters from three of the following five categories:
  • Uppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)
  • Lowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
  • Base 10 digits (0 through 9)
  • Non-alphanumeric characters (i.e., ~!@#$%^&*_-+=`|\(){}[]:;”‘<>,.?/ )
  • Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.
• Prior passwords are remembered and cannot be used for up to ten (10) setting cycles

Hosted Services

For hosted and SaaS services (e.g., Salesforce) used at LEVEL ACCESS, the same rules for the creation and updating of passwords defined in the Desktop Password Policy are applicable. In addition, when hosted services provide two-factor-authentication options, employees should activate and use these options whenever possible and practical.

Desktop System Lockout

Desktop computers are configured to automatically lockout inactive users after a fifteen (15) minute period of inactivity. In addition, as part of the Information Security and Privacy Training, LEVEL ACCESS trains users to ensure that any devices that are not automatically configured for lockout are configured on a per device basis.

Desktop System Delivery

LEVEL ACCESS receipt, setup, and configuration of computer equipment conforms to our standard IT build out specifications. Third party equipment is not allowed on core networks without authorization.

Encryption

In Transit

All network transmissions to the end user are sent over TLS using Rapid SSL signed a SHA 256 RSA signature algorithm. Transport Layer Security (TLS) 1.2 is used for stream encryption.  In addition, database connections with the application servers utilize SSL (AES-256) to secure data in transit.

For self-hosted AMP instances, the only data exchanged between the client and Level Access is installation/update files and database dumps. The database dumps contain primarily diagnostic data that is the result of AMP performing accessibility test on the assets submitted to it. All data is transferred via HTTPS using a HTTP client such as a web browser or FTP service with FTP services only at the explicit request of the client. All interchanges are done in real-time.

All data moved on physical media is encrypted during transit.

At Rest

All data stored in the databases is encrypted while at rest.  In addition, data stored in automated backups, snapshots, and replicas are all encrypted.

Encryption Key Management

LEVEL ACCESS encryption keys – both server and database – are managed using AWS Key Management Service.

Data Handling

Data Segregation

All client specific data and systems are segregated. The segregation either occurs physically or logically, depending on the subscription agreement and specific client terms. This allows for a strict separation of data that only permits users who have specifically been granted access to access the system.

Data Holds

This data segregation is sufficient to allow for data holds and record captures in response to client subpoena, forensics incident, or other direction. All legal hold actions are completed manually.

Production Data Use

Client specific production data is not copied or otherwise transferred or used in non-production environments. Production data is only available in production, and backups and is not used in any other way.

Removable Drive and Media Use

No client data will be copied, used, or otherwise transferred onto removable drives or media without the client’s clear and explicit permission and direction.

Data Handling Changes

Any changes to information processing or data handling procedures, facilities, or methods will follow documented controls and be communicated to the client materially in advance of implementation.

Secure Disposal

Any media containing client specific data will be disposed of in a manner which eliminates the potential for the data to be compromised, reconstructed, or otherwise accessed in a substantive fashion.

Data Purging

AMP uses the MySQL database to store data, and client database administrators are able to archive and purge data as necessary using the tools available in the MySQL Toolkit when hosting on-premise. This can be automated or manual depending on the client’s approach, as self-hosted clients administer their database on their own AMP instances. It is able to be configurable if built that way by the client.

For multitenant and client specific hosted instances, data purge requests are handled as requested on a per client basis.

Jurisdiction Control

If needed, LEVEL ACCESS will work with clients on a case-by-case basis to provide the Services in a specific physical location to ensure that clients can utilize the services from specific legal jurisdictions and control where their data is stored, processed, transmitted and / or accessed. These requests are handled on a case-by-case basis and may be subject to additional costs depending on the required jurisdiction hosting needs. In addition, clients can easily control jurisdictions through the simple expedient of deploying AMP directly into their own data center.

Data Ownership

Data ownership issues are defined and addressed as part of LEVEL ACCESS’s Master Subscription Agreement or the relevant agreement between LEVEL ACCESS and the client controlling client’s access to the services. In general, LEVEL ACCESS owns all pre-existing information and functionality provided by the Services “out of the box,” and the client owns all client specific data uploaded into or processed by the service by or on behalf of the client.

Logging and Monitoring

Network Logs

LEVEL ACCESS actively maintains and reviews system logs on all of its application servers. These logs are aggregated in a central location using Amazon’s CloudWatch technology and reviewed regularly to identify an anomalous activity. CloudWatch’s alert system informs the responsible individuals via e-mail if the logs are not created or if certain types of activity are detected. These audit logs are read-only logs that do not allow users to modify them.

Application Logs

AMP provides an internal logging system that tracks authentication and access to system assets by logging user IDs, asset IDs, and timestamps. The internal logs record individual User IDs, IP Address, Event type, Object ID, and Timestamp. All authentication attempts, successful or unsuccessful, are logged as well as accounts that are disabled due to repeated failed login attempts.

System Monitoring

LEVEL ACCESS provides support for remote monitoring functions on a per client basis in line with industry standard monitoring protocols.

Log Retention

Production system logs are retained for a minimum of one year.

Log Access

Access to all log files – network, operating system and application – is tightly restricted to specific named resources on a need to know basis.

Physical Security

Production Server Location and Access

AMP uses Amazon’s AWS Northern Virginia data center service. The data center provides a Tier 1 rating based around AMP’s software installation. Amazon (AWS) makes use of industry standard hosting security practices. Access to AWS data centers is tightly controlled and makes use of state-of-the-art electronic surveillance and multi-factor access control systems, in addition to being staffed 24/7 by trained security guards. This includes:

• 24/7 on-site security and NOC staff
• Alarm system with camera surveillance covering the entire perimeter of the building, throughout the data center area and all entrances and exits
• Secure entrances include mantraps, biometrics, key card access, and multi-factor authentication
• Pin #’s and security codes used are regularly updated.
• State-of-the-art monitoring system provides real-time data on equipment operation, enabling easy system management and instant identification of problems such as fires. Monitoring includes power and cooling systems, as well as temperature, humidity, leak detection, and fire protection.

All personnel are screened when leaving areas housing client data. In general, no access to hosting facilities is provided to non-Amazon personnel.

Work Area Access

LEVEL ACCESS provides limited access to all work areas based on building standard security and badge access.

Onsite Server Access

All onsite server access – which only includes servers used for LEVEL ACCESS’s internal IT systems – is provided to specific, named entities. Server access is tightly controlled and servers are in locked closets.

Escort

Access by any third party to LEVEL ACCESS offices is severely limited, and access is only provided with an escort by an LEVEL ACCESS representative. All third-party access must be validated and approved by a Director or higher level member of the LEVEL ACCESS management team and the approval documented via e-mail with a CC to LEVEL ACCESS’s information security personnel.

Network Access

Only specific device authorized access is provided to LEVEL ACCESS core networks. Guest access and non-LEVEL ACCESS owned device access is provided to a separate, segmented guest network.

Badges and Identification

LEVEL ACCESS does not currently require individual employees to utilize and wear an LEVEL ACCESS-provided photo badge. Given the company’s size, all employees in each physical office know and can identify one another. In practice, physically grouped teams remain small enough for all parties to know one another directly. As LEVEL ACCESS grows, the requirement for photo badges may change or increase.

Network and Operating System Security

Firewalls

LEVEL ACCESS uses hardened Linux servers behind firewalls, and these servers can only be accessed over encrypted connections. Firewalls are configured both at the server level and network level via AWS’s Virtual Private Cloud (VPC) network traffic restriction.

Penetration Testing

LEVEL ACCESS conducts quarterly Operating System and Penetration Testing using GuidePoint Security. The results of these tests are then communicated to the AMP staff, prioritized, and any issues are resolved as a part of the ongoing software and network infrastructure development process.

Intrusion Detection and Prevention

LEVEL ACCESS does not currently utilize an anti-intrusion system (IDS) in production servers and instead focuses on providing hardened Linux servers hosted in an AWS environment. LEVEL ACCESS is, however, actively exploring how to deploy an IDS in the AWS environment and is focused on implementing this as soon as possible.

Asset Ownership

All network assets have specific owners that are responsible for their maintenance and configuration in conformance to this information security policy. The tracking occurs via a central database administered by LEVEL ACCESS’s IT group. This database tracks who owns what and explicitly assigns each piece of hardware to a user. Assets are labelled and named individually and then deployed to the members of the team. Hardware access and password format and policy are all enforced centrally.

Asset Classification

All network assets are identified and classified based on the nature of their use and potential information security risk. All assets that have access to client specific data are grouped at least in medium risk asset categories. All assets that store client specific data are grouped into high risk asset categories.

DDoS Attack Mitigation

LEVEL ACCESS’s primary focus for DDoS attack mitigation is to limit the surface area for an attack by severely restricting the ports on production servers that are available to the general public. In general, this includes solely allowing port 80 to be available for redirect and to have all core traffic go through port 443. All other ports are only opened for as needed services and to specific IP addresses on LEVEL ACCESS controlled networks. This configuration occurs at the AWS Virtual Private Cloud (VPC) infrastructure level and is enforced natively by AWS.

Buffer Overflow Mitigation

AMP is written in a combination of Java and PHP and does not execute native operating system commands or system calls. Both Java and PHP are sandboxed, interpreted languages that utilize automatic memory management and are generally directly susceptible to buffer overflow attacks, as all memory access is permission and bounds checked in the execution environment.

All system daemons are routinely and actively patched on all production machines. In addition, all system daemons run as non-root users and have access only to specific chroot defined subset of the file system.

Personnel and Human Resources Policy

Background Checks

LEVEL ACCESS screens all employees for criminal and credit background checks. In addition, LEVEL ACCESS performs reference checks for each employee. LEVEL ACCESS does not, as a general rule, utilize contractors in the creation or delivery of any services or products the company develops or delivers. Currently, LEVEL ACCESS only conducts background checks at the time of employment of the individual. For sensitive clients or contracts, background checks can be conducted on a more frequent basis.

Code of Conduct

Each employee is required to sign Level Access Employee Handbook and an AT WILL EMPLOYMENT, CONFIDENTIAL INFORMATION, INVENTION ASSIGNMENT, AND ARBITRATION AGREEMENT prior to beginning employment. This includes LEVEL ACCESS’s code of conduct and confidentiality provisions as they relate to information security and data handling.

Information Security and Privacy Training

Formal training on the information security and privacy policies occurs on an annual basis and includes both lecture and self-paced training, as well as passing a specific validation program for security.

LEVEL ACCESS’s employee handbook includes information security requirements and information on LEVEL ACCESS’s standard information security policy. LEVEL ACCESS employees agree to follow specific information security policies as part of their onboarding process.

In addition, LEVEL ACCESS consultants and staff complete a variety of training programs on information security for specific clients based on the client’s information security policy needs.

Discipline and Non-Compliance

Non-compliance with the Information Security policy are handled on a case by case basis, and disciplinary measures range from retraining to dismissal.

Role Changes and Termination

LEVEL ACCESS’s standard termination policy includes a review and termination of all access rights to information systems. Access is removed prior to notification of termination or change of status. In addition, individuals are required to return all assets (laptop, desktop, PDA, cell phones, access cards, tokens, smart cards, keys, proprietary documentation) upon termination.

U.S. Federal Government Information Security Conformance

LEVEL ACCESS conforms to a variety of U.S. Federal government laws and standards relating to information security.   These include, but are not limited to the provisions outlined in the Federal Information Security Management Act (“FISMA”) of 2002, the Clinger-Cohen (“Clinger-Cohen”) Act of 1996 and the Privacy Act (“Privacy Act”) of 1974.  The requirements of these Acts are promulgated in a variety of standards and policies relating to information security that apply at government-wide, department-wide and agency specific levels.

An overview of LEVEL ACCESS’s approach to conforming to the relevant laws, standards and policies is provided below.  This includes a high-level overview of LEVEL ACCESS’s conformance to a variety of Federal Information Processing Standards (FIPS), National Institute of Standards and Technology (NIST) publications and agency specific approaches.   This is not meant to provide an exhaustive description on conformance or LEVEL ACCESS’s information security approach – rather a high level, overview of our approach

LEVEL ACCESS understands that the process of receiving and Authority to Operate (ATO) for an application with a Federal government agency requires investment on the part of the vendor and the agency seeking the ATO.  LEVEL ACCESS is committed to working with agencies personnel to jointly navigate this process and make it as smooth as possible.

FIPS 200 Conformance

Title III of the E-Government Act – generally referred to as the Federal Information Security Management Act or FISMA – requires that each Federal agency develop an organization-wide program to manage information security.  These programs are broadly defined and reach into all aspects of the agency’s information technology.   As part of supporting these programs, FISMA directed the Department of Commerce to develops standards for “(i) the security categorization of federal information and information systems based on the objectives of providing appropriate levels of information security according to a range of risk levels; and (ii) minimum security requirements for information and information systems in each such category[1].” FIPS Publication 200 does this by defining a risk categorization approach for systems – further defined in FIPS 199 – and the minimum security requirement areas all Federal information systems must consider and address in their policies.

Classification

Under FIPS 200 each Federal agency is required to determine the Information System Impact Level for systems under their control. LEVEL ACCESS currently recommends that Federal agencies classify LEVEL ACCESS systems as low-impact information systems.  This classification is based on FIPS 199 – Standards for Security Categorization of Federal Information and Information Systems.  Under FIPS 199 there are three categorization factors – confidentiality, integrity, and availability that must be considered in determining the final classification of the system:

• Confidentiality – Confidentiality is defined as “Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information…[2]”. Broadly a “loss of confidentiality is the unauthorized disclosure of information[3].”  LEVEL ACCESS systems generally only store (i) publicly available data or (ii) data on the basic presentation structure of an application.  Both of these types of data are generally considered “low risk” if they were exposed or disclosed outside of the system.  For more information on the types of data LEVEL ACCESS stores please see our Privacy Policy – available on request from LEVEL ACCESS.
• Integrity – Integrity is defined as “Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity…[4]” In plain terms it is a “loss of integrity is the unauthorized modification or destruction of information[5].” LEVEL ACCESS systems are used to store temporary, interstitial testing results that are generally not used on an ongoing basis.   The unauthorized modification or loss of any of the information stored in LEVEL ACCESS systems is highly unlikely to have any systemic impact to the procuring agency.
• Availability – Availability is defined as “Ensuring timely and reliable access to and use of information…[6]” In common understanding a “loss of availability is the disruption of access to or use of information or an information system.[7]” LEVEL ACCESS systems are seldom considered mission critical and are used infrequently at various, discrete points throughout the software or content development lifecycle.   Their unavailability is unlikely to have any degree of broad or systemic impact on the organization using them.

In all cases the loss of confidentiality, integrity, or availability would reasonably be “expected to have a limited adverse effect on organizational operations, organizational assets, or individuals”    and would qualify as a low-impact system as defined in FIPS Publication 199.   This aligns with LEVEL ACCESS’s general view that the systems are not mission critical systems and pose low information security risk.

Minimum Security Requirements Mapping

FIPS Publication 200 defines a variety of Minimum Security Requirements that defines areas of information security that must be addressed in agency and contractor information security policies.   The following table provides a mapping between each of these requirements and the relevant section(s) of Level Access’s Security Policy that define the method of conforming to that requirement.

Requirement	FIPS Language	LEVEL ACCESS Security Policy Relevant Sections
Access Control (AC)	Organizations must limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems) and to the types of transactions and functions that authorized users are permitted to exercise.	Access Control Logging and Monitoring
Awareness and Training (AT)	Organizations must: (i) ensure that managers and users of organizational information systems are made aware of the security risks associated with their activities and of the applicable laws, Executive Orders, directives, policies, standards, instructions, regulations, or procedures related to the security of organizational information systems; and (ii) ensure that organizational personnel are adequately trained to carry out their assigned information security-related duties and responsibilities.	Information Security and Privacy Training
Audit and Accountability (AU)	Organizations must: (i) create, protect, and retain information system audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity; and (ii) ensure that the actions of individual information system users can be uniquely traced to those users so they can be held accountable for their actions.	Logging and Monitoring
Certification, Accreditation, and Security Assessments (CA)	Organizations must: (i) periodically assess the security controls in organizational information systems to determine if the controls are effective in their application; (ii) develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational information systems; (iii) authorize the operation of organizational information systems and any associated information system connections; and (iv) monitor information system security controls on an ongoing basis to ensure the continued effectiveness of the controls	Policy Review and Updates Software Security Policy
Configuration Management (CM)	Organizations must: (i) establish and maintain baseline configurations and inventories of organizational information systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles; and (ii) establish and enforce security configuration settings for information technology products employed in organizational information systems.	Change Control Process Network and Operating System Security Physical Security Software Security Policy
Contingency Planning (CP)	Organizations must establish, maintain, and effectively implement plans for emergency response, backup operations, and post-disaster recovery for organizational information systems to ensure the availability of critical information resources and continuity of operations in emergency situations.	LEVEL ACCESS’s Security Policy does not cover contingency planning.  Contingency planning is covered in LEVEL ACCESS’s Business Continuity and Disaster Recovery Plan that is available on request from LEVEL ACCESS.
Identification and Authentication (IA)	Organizations must identify information system users, processes acting on behalf of users, or devices and authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.	Access Control Network and Operating System Security
Incident Response (IR)	Organizations must: (i) establish an operational incident handling capability for organizational information systems that includes adequate preparation, detection, analysis, containment, recovery, and user response activities; and (ii) track, document, and report incidents to appropriate organizational officials and/or authorities.	Incident Handling
Maintenance (MA)	Organizations must: (i) perform periodic and timely maintenance on organizational information systems; and (ii) provide effective controls on the tools, techniques, mechanisms, and personnel used to conduct information system maintenance.	Software Security Policy Network and Operating System Security
Media Protection (MP)	Organizations must: (i) protect information system media, both paper and digital; (ii) limit access to information on information system media to authorized users; and (iii) sanitize or destroy information system media before disposal or release for reuse.	Data Handling
Physical and Environmental Protection (PE)	Organizations must: (i) limit physical access to information systems, equipment, and the respective operating environments to authorized individuals; (ii) protect the physical plant and support infrastructure for information systems; (iii) provide supporting utilities for information systems; (iv) protect information systems against environmental hazards; and (v) provide appropriate environmental controls in facilities containing information systems.	Physical Security
Planning (PL)	Organizations must develop, document, periodically update, and implement security plans for organizational information systems that describe the security controls in place or planned for the information systems and the rules of behavior for individuals accessing the information systems.	Policy Review and Updates
Personnel Security (PS)	Organizations must: (i) ensure that individuals occupying positions of responsibility within organizations (including third-party service providers) are trustworthy and meet established security criteria for those positions; (ii) ensure that organizational information and information systems are protected during and after personnel actions such as terminations and transfers; and (iii) employ formal sanctions for personnel failing to comply with organizational security policies and procedures.	Personnel and Human Resources Policy
Risk Assessment (RA)	Organizations must periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational information systems and the associated processing, storage, or transmission of organizational information.	Policy Review and Updates
System and Services Acquisition (SA)	Organizations must: (i) allocate sufficient resources to adequately protect organizational information systems; (ii) employ system development life cycle processes that incorporate information security considerations; (iii) employ software usage and installation restrictions; and (iv) ensure that third-party providers employ adequate security measures to protect information, applications, and/or services outsourced from the organization.	Software Security Policy
System and Communications Protection (SC)	Organizations must: (i) monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems; and (ii) employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational information systems.	Software Security Policy Logging and Monitoring
System and Information Integrity (SI)	Organizations must: (i) identify, report, and correct information and information system flaws in a timely manner; (ii) provide protection from malicious code at appropriate locations within organizational information systems; and (iii) monitor information system security alerts and advisories and take appropriate actions in response.	Software Security Policy Network and Operating System Security Policy

NIST Special Publication 800-53 Conformance

Based on the FIPS 200 Classification noted above LEVEL ACCESS has implemented full support for the low-impact baseline of security controls defined in NIST Special Publication 800-53.

Organization Specific Policies

Each Federal government agency has its own unique and specific policies that mix government wide requirements with Department and Agency specific requirements.   LEVEL ACCESS is committed to fully supporting each agency’s unique information security policy requirements and justifying that conformance in a fashion that readily maps to Federal government wide legal requirements and standards.   In this fashion procuring organizations can quickly justify conformance to all relevant information security requirements with minimal effort.

Expedited Review and Authority to Operate (ATO)

Many Federal government agencies provide for expedited reviews and Authority to Operate (ATO) for applications that meet certain thresholds.   For example, GSA Information Security Policy allows for Software as a Service (SaaS) solutions that have a specific profile to follow a streamlined approval process.   The requirements to enter into this approval process tend to be fairly narrow but are generally related to those systems that have a limited scope of use, involve data that is already publicly available or otherwise non-sensitive and fall under a certain dollar amount.   Such applications can follow streamlined approvals processes for quick deployment.  In these cases, both the business purchaser and the authoring authority or official most work to follow the streamlined process.

LEVEL ACCESS services may meet the requirements for these streamlined approvals for initial and pilot deployments.   During such deployments LEVEL ACCESS can work with the business and information security owners of the system to secure a more robust authorization to operate the system on a long-term basis.

Policy and Regulation Conformance

As part of our information security programs LEVEL ACCESS seeks to conform to the following government policies and regulations as they apply to Contractors and vendors of SaaS systems:

• Federal Information Security Management Act (FISMA) of 2002.
• Clinger-Cohen Act of 1996 also known as the “Information Technology Management Reform Act of 1996.”
• Privacy Act of 1974 (5 U.S.C. § 552a).
• Homeland Security Presidential Directive (HSPD-12), “Policy for a Common Identification Standard for Federal Employees and Contractors”, August 27, 2004.
• Office of Management and Budget (OMB) Circular A-130, “Management of Federal Information Resources”, and Appendix III, “Security of Federal Automated Information Systems”, as amended.
• OMB Memorandum M-04-04, “E-Authentication Guidance for Federal Agencies.”
• FIPS PUB 199, “Standards for Security Categorization of Federal Information and Information Systems.”
• FIPS PUB 200, “Minimum Security Requirements for Federal Information and Information Systems.”
• FIPS PUB 140-2, “Security Requirements for Cryptographic Modules.”
• NIST Special Publication 800-18 Rev 1, “Guide for Developing Security Plans for Federal Information Systems.”
• NIST Special Publication 800-30, “Risk Management Guide for Information Technology Security Risk Assessment Procedures for Information Technology Systems.”
• NIST Special Publication 800-34, “Contingency Planning Guide for Information Technology Systems.”
• NIST SP 800-37, Revision 1, “Guide for the Security Certification and Accreditation of Federal Information Systems.”
• NIST Special Publication 800-47, “Security Guide for Interconnecting Information Technology Systems.”
• NIST Special Publication 800-53 Revision 4, “Recommended Security Controls for Federal Information Systems.”
• NIST Special Publication 800-53A, “Guide for Assessing the Security Controls in Federal Information Systems.”

Assessment and Authorization (A&A) Activities

LEVEL ACCESS acknowledges that the Assessment and Authorization (A&A) process as defined in NIST Special Publication 800-37 will require material investment on the part of both parties to complete.  This includes the preparation of a variety of A&A documents for review by the agency and collaboratively working with relevant members of the agency team to complete the process and commit to remediation timelines that are appropriate for all parties.  In support to of this LEVEL ACCESS is committed to providing all the relevant forms of documents detailed in the A&A process as well as additional documentation that will be determine during the process that is necessary to successfully complete the process.   While this varies for each agency LEVEL ACCESS expects this will broadly include the following high level documentation:

• System Security Plan (SSP). A document that details the information security approach for the system.   In general, LEVEL ACCESS prepares these documents as modified versions of this security policy formatted in a fashion that will conform to the requirements of NIST Special Publication 800-18.  It will include all the relevant appendices including justifications for the related policies and procedures that map to the eighteen control families of FIPS 200.   In addition, it will address any organization or procurement specific requirements.
• Contingency Plan. A copy of LEVEL ACCESS’s current Business Continuity and Disaster Recovery Plan built in conformance with NIST Special Publication 800-34.
• Contingency Plan Test Report. A report outlining the results of testing the Contingency Plan as defined above.  Absent other agency direction this is completed in conformance to GSA IT Security Procedural Guide 06-29, “Contingency Plan Testing.”
• Plan of Actions & Milestones. The plan for addressing any conformance issues that arise in the A&A process particularly those relating to NIST 800-53.  Absent other agency direction this is completed in conformance with GSA IT Security Procedural Guide 09-44, “Plan of Action and Milestones (POA&M).”
• Penetration Test Reports. Penetration testing reports for operating systems, servers and application level testing.  These will document the result of vulnerability and exploit scans, static and dynamic testing and other penetration testing of the system.

Reporting and Continuous Monitoring

Once an ATO has been granted significant ongoing reporting and monitoring requirements remain in effect.   These includes a series of ongoing, quarterly and biennial reports and procedures reporting to the agency that provide confidence LEVEL ACCESS remains in conformance to the agency requirements.

[1] Federal Information Processing Standards 200

[2] 44 U.S.C., Sec. 3542

[3] FIPS 199

[4] 44 U.S.C., Sec. 3542

[5] FIPS 199

[6] 44 U.S.C., SEC. 3542

[7] FIPS 199