| Table of Contents |
|---|
Risks and Mitigation
...
Here we enumerate the risks, if they will be addressed, and detail how they the risk will be mitigated.
General Security Measures
Until we are better staffed to administer a public facing site, we shall allow only traffic from the city and county to access the site and web services. By adopting this simple and effective meaure, we can sidestep a number of other issues such as DOS and SQL injection attacks.
TODO - Will, can I ask you to do this work? I recall that we can use a subnet mask or equivelent.
Hardware Failure
Hardware failures are handled by applogic. As long as we do not use too many resources on a given grid, the hardware failover is automatic.
TODO - Will, is there a way we can be notified when there is a hardware failure? Do we need to do anything here?
Denial of Service Attacks
We will not be taking any specific measures to detect or to mitigate a DOS attack.
...
The application code uses a framework to escape all user input which effectively dispenses with this problem.
User Credential Security
Should we/can we We will not enforce strong passwords ?
TODO - Paul, check and see if we can do this.
Should we/can nor will we force password changes?
TODO - Paul, check and see if we can do this.
Each year we will conduct a user account audit and disable or remove all accounts that are not in use.
DEFER
System Administration Credential Security
administration credentials include:
ETL Processing
- windows user
...
- accounts (dev, qa, prod)
- ssh keys (dev, qa, prod)
Web Application
- applogic grid root
...
- ssh access to linux VMs
- tomcat
- geoserver
- postgres
...
- MAD application admin
- apache httpd
TODO - Paul - enumerate all these accounts, to be stored and maintained at a single unpublished location known to the support staff.
TODO - Paul - review all of the administration credentials, and do the following:
- insure that default passwords are not used
...
Viruses
We will not be scanning for viruses.
...
Database Integrity and Performance
...
We are using the Postgres database which is known for stability and robustness.
In any event, every 24 hours we
- run consistency checks
- run a full vacuum/analyze to guarantee good performance
- backup the database
- copy the backup to offsite location
- retain backups as needed (todo - need this from Hema)
TODO - Paul - automate all of this
TODO - Hema - we need your business schedule to do these things at a good time
Data Center Connectivity Lost
...
With each version release into production we will back up the entire application to a secondary data center. We will make database backups every 24 hours day and copy them to the secondary data centersecond VM for use upon failover. Should we lose the primary data center, we will bring up the application in the secondary data center using the most recent database backup. ? Performance of the application for the first day will be sluggish because the map cache will be empty/out of date. It will take overnight to reseed the map cache which can be done from the command line on the ETL machine.
TODO - add job to completely reseed the map cache (Paul)
...
Database Integrity
...
We are using the Postgres database which is know for stability and robustness.
In any event, every 24 hours we
- run consistency checks to insure integrity
- run a full vacuum/analyze to guarantee good performance
- backup the database
- copy the backup to offsite grid
- report any issues to application support
TODO - Paul with help from DBA and Willtodo - Paul - test
todo - need input from Hema here.
Deployment practices
The Enterprise Addressing System includes a data server, a map server and a web server. The application deployment are managed using standard practices with 3 separate environments (DEV, QA, PROD). Changes of any sort are first tested in the DEV environment. If the tests pass, we apply the changes to QA where business users conduct testing. Only after the business users approve the changes do we release any changes to PROD. This includes everything from OS upgrades through to our own application code, minor and major.
...
Disk Space
Every 24 hours we
- check that there are no disk space issues
- notify application support if there are any issues
TODO - Will, can I ask you to look at this? Paul can help.
Failover
Before we go into production and once every year, we will conduct a failover exercise to ensure that we are able to provide business continuity.
TODO - Paul
Service Level Agreement (separate docs?)
...
Who will provide Bug Fixes and Enhancements?
...
How will we decide what bugs get fixed and what enhancements are built (governance)?
...
Maximum time allowed for ETL outage.
...
Recovery Time Objective
...
Without MAD, DBI will not be able to issue permits. (Is this correct?) The recovery time objective for the application is 2 hours. Hema, is this acceptable?
...
Recovery Point Objective
...
The recovery point objective for the database is 24 hours. Hema, is this acceptable? I am assuming that, given our limited resources, we will use database backups for recovery, and that we do not want to use replication. If we were to use replication, we could have a recovery point objective right down to a single transaction. But we have no expertise here and so I recommend against this approach.
Administration Roles
We need some wiki pages and some bodies - detailed belowtodo - Hema, is all this acceptable?
Support Notifications
At a minimum we will use email for support notification. This means we'll need access to a mail server or some sort. And depending on DBI requirements, including their schedule requirements, we may consider a more robust solution such as Nagios. Using Nagios would probably mean more work; I have no experience with Nagios but some DT staff do.
Administration Roles
We need to flesh out who is going to do what...
...
Virtual Machine Admin
...
Can our ASP provide this until we move to 200 Paul?
user administration
TODO - Hema, can DBI help with this?
...