Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

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
  • development practices

Mitigation of Risks

The following section details the risks, if they will be addressed, and how they will be mitigated.

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

We will not be taking any meaures to detect or to mitigate a DOS attack.

SQL Injection Attacks

The application code uses a framework to escape all user input which effectively dispenses with this problem.

Credential Security

Should we/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

todo

data center is physically destroyed

todo

data center connectivity is lost

todo

database is corrupted

todo

production support

todo

key person risk

todo

Deployment practices

The MAD application 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.

For various legacy oriented reasons, we were unable to employ standard practices for the extract, transform, and load (ETL) processes. While this process has been coded to support DEV, QA, and PROD environments, none of the participating systems have more than a single environment. (Is this correct?) This includes each of the data servers (SFGIS, DPW, ASR). The workstation that execute the ETL is virtualized but is not backed up and has no failover plan in place. (Is this correct?)

Development Practices

The software development team uses version control (Subversion), bug tracking (Jira), wiki collaboration (Confluence), all of which is hosted by Atlassian. All source code, ddl, dml, design documents, etc are stored on Atlasian. When a version is released, the repository is tagged. When bug fixes are made to production, a branch is create in the repository.

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

  • No labels