Chapter 10: Systems Development and Maintenance

2

Objectives

Appreciate the importance of creating new software solutions with security in mind from the genesis of the project

Build code that protects the security of the sensitive data on which it relies

Use cryptography in application systems

3

Objectives Cont.

Understand the intricacies of path management and system availability as they relate to both operating system files and application system files

Apply policies related to systems development and maintenance

4

What Are the Risks to the Organization? What are the risks of “sloppy code” to the

organization? Untested and/or sloppy code can lead to attacks

against the confidentiality, integrity and availability of the corporate data

This can lead to: Financial issues Legal responsibilities, and potentially active litigation Loss of reputation

5

Systems Development

Code created from scratch to build a line-of-business application

Code may be written in-house or out-sourced Security MUST be included in the project from the

start

6

Systems Maintenance

No code should remain static: New vulnerabilities are discovered every day New features are needed

Also relates to the software platform on which the code runs Operating system must also be patched Patches must be tested to make sure that they have no

negative impact on: The OS The line-of-business application

7

Security Requirements of Systems

Security must be taken into account form the genesis of the project

Retroactively attempting to inject security back into existing code usually either does not work, or ends up creating new vulnerabilities and/or instability in the code

8

Risk Assessments

At the beginning of the project, a risk assessment should be conducted to identify and document all potential risks associated with the project

Risk management decisions are based on: The results yielded by the risk assessment The classification of information The sensitivity of the information The business value of the information

9

Security Requirements of Systems Cont.3rd-party consultants: required?

Cons: Cost – or perceived cost Feeling that they will make the in-house developer “look

bad” Pros:

A fresh pair of eyes 3rd-party oversight (Separation of duties)

10

Security Requirements of Systems Cont. Adding controls after implementation

It’s a bad idea Proves that the security process during the creation of the

code did not occur as planned Fixing known security issues retroactively also can create

ancillary vulnerabilities This said, can a newly identified vulnerability be ignored?

What is the degree of sensitivity of the data at risk? What is the cost to eradicate the risk? What is the probability this risk will become an exploitable threat?

11

The Things that Should Never Happen to Sensitive Data! Data loss

Threatens data availability Exposes the company to:

Potential litigation Loss of reputation Financial loss

12

The Things that Should Never Happen to Sensitive Data! Cont. Data modification

Threatens data integrity & confidentiality Data that has been tampered with comes in two types:

Data tampering is discovered, and measures are taken to bring back the original data

Data tampering is not discovered, and the company continues to proceed with its regular business tasks based on faulty information

13

The Things that Should Never Happen to Sensitive Data! Cont. Data misuse

The data is legitimate The way the data is used is not legitimate Includes such activities as corporate espionage Involves an employee accessing data they are not

supposed to because of failing access control and using this data either maliciously, or for their financial gain

It is the responsibility of any employee to alert management if they discover a faulty access control. Failure to do is seen as a malicious, dishonest act

14

Sloppy Code vs. Secure Code

Sloppy code: Can be the result of:

Amateurish effort Flawed security process Rush to market/production

Secure code Is the result of:

Careful planning Taking security into account from the start of the project Thorough testing

15

Sloppy Code vs. Secure Code Cont.

System owners It is their responsibility to deploy secure code Must be carefully identified Must be trained to understand their responsibility If training is needed, the sooner it is provided, the better

16

Sloppy Code vs. Secure Code Cont.

Input validation Inspects dynamic information entered into an application

system to make sure that it is legitimate information All information entered that is identified as non-

legitimate will be discarded and not handled further by the application system

17

Sloppy Code vs. Secure Code Cont.

Input validation Hackers use poor input validation to

Run commands on the target server via the faulty application system Attack on data confidentiality, integrity and/or availability

Access sensitive information they are not authorized to view Attack on data confidentiality

Shut down a targeted server Attack on data availability

18

Risk Assessments and Cryptography

Cryptography: the process that takes plain text and turns into ciphertext

Ciphertext: text that cannot be read unless you apply the correct algorithm and predetermined value

The predetermined value is also referred to as a key

The key must be securely stored and strong enough to resist brute force cracking attempts

19

Risk Assessments and Cryptography Cont.

Risk assessment: should always be conducted for any new development project

Should outline which data should never be transmitted in clear text

Rule of thumb: any data classified as “sensitive” should also be sent in encrypted format

Encrypting all traffic is not the answer as it places undue overhead on the server and slows down transactions

20

Risk Assessments and Cryptography Cont.

Digital signature: Digital code appended to an email Insures non-repudiation and data integrity Does not insure data confidentiality

21

Risk Assessments and Cryptography Cont. Protecting the encryption keys

Compromised keys mean that the confidential data is not safe anymore

Worse if the company does not know that the key has been compromised as it will continue to rely on it use it to send confidential data, thinking that it is secure

Someone must be officially responsible for the security of the keys Usually, it is a senior IT employee, in correlation with the

Information Security Officer

22

Risk Assessments and Cryptography Cont.

Key management includes: Acquiring the digital certificates Assigning digital certificates to application systems Maintain the revocation lists Retiring keys

Two kinds of digital certificates: Published by a 3rd-party Certification Authority (CA)

For external use Internally published

For internal use

23

Risk Assessments and Cryptography Cont. Key management includes:

Keys should not be reused on several application systems

Rule of thumb: one key per application system A certificate policy should be created

A document that defines the exact circumstances under which each certificate will be used

Digital certificates have a an expiration date Usually one year after issuance Can be, but should NOT be renewed

24

Risk Assessments and Cryptography Cont. Digital certificates can be revoked

Usually a bad sign! It means there is a chance that the key has been compromised

If there’s the slightest chance that a key may have been compromised, the digital certificate MUST be revoked

Revocation lists are kept to verify that a given certificate has not been revoked

Certificates can be suspended, when it is known that it won’t be used for a period of time

Key destruction must occur before a hard drive is reused

25

Risk Assessments and Cryptography Cont. Encryption and business partners

Anytime two companies exchange sensitive information electronically, this information MUST be encrypted while in transit

Often used in the context of an extranet

26

Operating System and Application Software Stability

If the OS platform is not stable, the application system it hosts will not be stable either

Any OS vulnerability is, in turn, a potential vulnerability for the application system

The application system may have the most rigorous and efficient built-in security controls. If the OS on which it relies is not secure, the application and the data it generates are still very much at risk

27

Operating System and Application Software Stability Cont.

Only stable versions should be deployed on production servers Code exists in two versions: stable and in development. Beta release code should not be place in production

because: It may not be stable

May result in data unavailability, loss and/or corruption It may not be secure yet

May result in loss of data confidentiality and/or integrity

28

Operating System and Application Software Stability Cont. Updates: required, dangerous or both?

Software updates require their own policy Known as patch management policy Difference between software update and upgrade:

Update: a known issue with the current release is fixed Upgrade: a new release is made available

Why update? To fix an identified security vulnerability To make the application more stable A new feature is added

29

Operating System and Application Software Stability Cont. Because an update is available does not

mean that is must be applied right away Some patches are simply faulty Some patches require a reboot, which may not be

possible in the middle of the day on a production server Some patches may work for 99% of the environments

and crash the remaining 1% A complete recovery procedure should be created,

tested documented and authorized before a patch is installed on a production server

30

Operating System and Application Software Stability Cont. Sometimes the patch should be applied

ASAP: If it fixes a security vulnerability that has already been

exploited and places a production server at high risk If the server is extremely unstable as it is, and the patch

is supposed to fix that instability problem

31

Operating System and Application Software Stability Cont. Updates: who should apply them?

Only authorized users should apply patches These users should be trained and officially in charge of

patch management They usually are members of IT or 3rd-party consultants Developers should NOT be allowed to unilaterally deploy

their own patches (Separation of duties) All patches should be subject to a change management

review and authorized by system information owners

32

Operating System and Application Software Stability Cont. Testing Environment Concerns

Companies SHOULD have a test environment The closer to the live environment the test environment is, the

more expensive it is, but the more accurate the testing will be The cost of setting up the test environment should be

compared to the cost of a loss of data confidentiality, integrity and/or availability because of a patch-related reason

Testing environment should be 100% segregated from the live network

33

Operating System and Application Software Stability Cont. Testing environment and live data

Live data should NEVER be used in a test environment The test servers may not be as well secured as the live,

production servers People with admin-level access to the test server may

not have the same privilege levels on the live server Simulated, or dummy, data should be used in place of

live data

34

Summary

Data availability needs are at an all-time high. Custom applications must be created with security in mind from the start of the project, which includes a risk assessment and proper input & output validation, along with regular security tests.

Patching a server is not a trivial task, and should be accomplished according to the path management policy.