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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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:
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 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.
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.
All development, test, and production systems are separate. They operate on different network systems and provide different levels of access.
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.
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.
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.
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.
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.
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.
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 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.
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.
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, 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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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 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.
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:
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 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.
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.
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.
All data stored in the databases is encrypted while at rest. In addition, data stored in automated backups, snapshots, and replicas are all encrypted.
LEVEL ACCESS encryption keys – both server and database – are managed using AWS Key Management Service.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
LEVEL ACCESS provides support for remote monitoring functions on a per client basis in line with industry standard monitoring protocols.
Production system logs are retained for a minimum of one year.
Access to all log files – network, operating system and application – is tightly restricted to specific named resources on a need to know basis.
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:
All personnel are screened when leaving areas housing client data. In general, no access to hosting facilities is provided to non-Amazon personnel.
LEVEL ACCESS provides limited access to all work areas based on building standard security and badge 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Non-compliance with the Information Security policy are handled on a case by case basis, and disciplinary measures range from retraining to dismissal.
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.
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.
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.” 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.
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:
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.
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
|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
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
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.
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.
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.
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:
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:
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.
 44 U.S.C., Sec. 3542
 FIPS 199
 44 U.S.C., Sec. 3542
 FIPS 199
 44 U.S.C., SEC. 3542
 FIPS 199