Secure Software Design
Software design is often discussed in the form of guiding principles or design patterns. We’d like to present two favorites in secure software design.
Security Logging
Logging is a very important part of a security critical system. It is used for runtime monitoring of security relevant events as well as after-the-fact analysis. The quality of the logs can be ensured by the right design.
To allow for efficient and effective log analysis the log messages need to be consistent. Standard logging frameworks do not enforce consistent logging. For instance the java.util.logging.Level gives the following scale:
- SEVERE
- WARNING
- INFO
- CONFIG
- FINE
- FINER
- FINEST
A design solution presented by Sethi and Bhalla [1] is to add a wrapper log object that has specific methods for every type of logging such as security logging. The methods should also support a linear priority level scale. For example:
logDebugMessage(logMessage, priorityLevel, callingClass)
logSecurityMessage(logMessage, priorityLevel, callingClass)
logSystemMessage(logMessage, priorityLevel, callingClass)
This concentrates formatting of log messages to the wrapper object. A good addition is to automatically include a unique thread ID in the log messages so that various log files can be matched easily.
Privacy
Privacy in IT systems is an important issue. With the power of computers huge amounts of information can be processed in short time which allows for information aggregation, data mining and cross-referencing. Therefore it is important to think about privacy implications already during application design.
The most important privacy concerns in system design are:
- Logging. What should the system log? Is any of that information privacy relevant? Can we anonymize it? Who will have access to the logs including access to log backups? If privacy relevant information such as traffic analysis that can be tied to a person is going to be logged the users should be informed.
- Social security numbers, credit card numbers, and the like. Are we going to store key values that can be tied to a person? Do we need to? Can they be anonymized for instance through salted hashing? Or can we at least encrypt them?
- Legislation and compliance. Was does the law say about storing or handling the kind of privacy relevant information we do? Do our business partners require us to be compliant in any way such as fulfilling the Payment Card Industry Data Encryption Standard [2]?
References
[1] R. Sethi and N. Bhalla. Building Secure Applications: Consistent Logging. SecurityFocus, February 26, 2007.
[2] Payment Card Industry Data Encryption Standard, PCI DSS.
Submitted by John Wilander (john.wilander@omegapoint.se) in partial fulfillment of the CSSLP experience assessment requirements.
Inga kommentarer:
Skicka en kommentar