This page enumerates production risks and mitigation measures.
Risks
- hardware failure
- denial of service attacks
- SQL injection attacks
- credential security
- viruses
- data center is physically destroyed
- data center connectivity is lost
- database is corrupted
- production support
- key person risk
- deployment practices
Hardware Failure
todo
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.
Denial of Service Attacks
Therefore we will not be taking any meaures to detect or to mitigate a DOS attack.
SQL Injection Attacks
See "Denial of Service Attacks" section above. The application code uses a framework to escape all user input which effectively dispenses with this problem.
Credential Security
Can we enforce strong passwords?
Should we/ can we force password changes?
Each year we will conduct a user account audit and disable or remove all accounts that are not in use.
Viruses
See "Denial of Service Attacks" section above.
data center is physically destroyed
data center connectivity is lost
database is corrupted
production support
key person risk
deployment practices
Mitigation of Risks
Environments
With respect to the MAD application itself, changes of any sort are first tested in the development 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.
To push normal street and parcel data changes into the MAD, we us an extract, transform, and load (ETL) process. While this process has been coded to support (DEV, QA, PROD) environments, none of the participating systems have more than a single environment. (Is this correct?) This includes the machine that the ETL jobs run on, the SFGIS dataserver, the DPW data server, and the ASR data server. FME workstation is not being backed up, is virtulaized , etc.
Recovery Time Objective
Without MAD, DBI will not be able to issue permits. (Is this correct?)
The recovery time objective for the application is 1 hour. (Is this OK?)
Recovery Point Objective
The recovery point objective for the database is 8 hours. (Is this OK?)
In some cases, such as a data center failure, the map cache that we fail over to
will be unseeded. The cache can be reseeded over night but the responsiveness
of the entire application will be slow until the the cache is reseeded.
access to the database is more important than access to the cached map data
upon a DC failover, we will have to reseed chache
Can we assume that we are not going to use replication?
If no replication, how much work can we loose? (1 day, 4 hours?, 2 hours?)
monitor disk space
0 Comments