We are currently pursuing an ATO (Authority To Operate) for some of our Tools. We are working with a company named Lunarline in the process.
We are still in process, but I wanted to lay out a few things we have learned in the process for consideration on current and future tools, and I thought this may help others as well.
Technology Roadmap
- In order to be compliant with current STIGS (Security Technical Implementation Guide) sites need to be running WINDOWS OS 2012 and SQL 2012. Obviously we still need to support sites that have been mandated to change but who have not yet got funding or implemented the change.
- Sites should be running .Net 4.0 as well. There are still some laggards.
- Services are being pushed from local sites to MATCOM. There is an current mandate to have sites switched over to Windows 10 by January or February 2017. This means we may need to support the EDGE browser.
Documentation
I think we will know much more about this next week, but for now there are a few things we can do going forward.
Ports and Protocols
This is a huge thing in the STIGS. We should reference any ports we want them to use and modify the installation documents to have them write down the ports and protocols they configured for our application if different than the defaults.
For example: “We recommend the Default SQL port 1433 be used on the SQL instance. If you configure the application to use a different SQL port specify it here ________________________”
Documentation on configuration options for IIS Server and IIS Websites should be also be specified.
Service Accounts
We typically have sites create a SQL login with access to our application databases. In the past we have recommended they be named something like Tool_Dashboard_User. We should change this to Tool_Dashboard_System since they are actually service accounts for the tool.
This is because the sites are required to change User accounts (belonging to a specific person) every 60 days. However, they only have to change system account passwords annually. Changing our default will make it easier for the sites to recognize we are using a system account when they are assessing accounts that require changes.
Versioning
We need to be cognizant of modifications we make to applications after we get an ATO. If you go from a major revision to another major revision (3.0 to 4.0) you need to go through ATO process again. However, if it is only a minor revision (3.0 to 3.01 or 3.1) you do not need to go through it again.
They classify a major revision a significant change in the installation configuration (objective) or functionality (subjective).
We just have to be smart about our versioning.
Most of what we will probably have to do for our applications are adding tons of documentation on how we develop, test, deploy etc.
It sounds like most of the assessment we fall into will be site / system STIGS which we are not accountable for – such as SQL Server. Servers get a significant assessment. However, there is only a small assessment for a specific database.
We will know more next week when go through an interview with another security person at Lunarline.
I will keep you updated.
