A security pattern describes a particular recurring security problem that arises in a specific context and presents a well-proven generic scheme for its solution. The key question is how information can be structured to reflect the needs of the security domain.
There is a formal way of describing patterns. GHJV patterns were all described using a specific format. This paper uses those ideas and modifies and extends wherever necessary in description. This paper describes 7 patterns and also tries to create a pattern language for emphasizing the co-relation that exists in between. If we follow the GHJV paradigm and try to classify the patterns as structural, creational and behavioral, Single Access Point, Checkpoint, Roles and Secure Access Layer are structural, Session is creational and Limited View and Full View With Errors are behavioral. Trying to come up with such classification is important because it clarifies the context and applicability. Later John Viega defined 10 security principles for software and charted a classification based on these principles. This paper is important because it provided the idea that architectural qualities like security ca show recurring traits and therefore can be mined into patterns. There has been a proliferation in the number of security patterns documented from this point onwards. Many of these patterns are middle-level design patterns and work on specific aspects like cryptography, some are system specific like Windows and Unix OS specific patterns. The patterns in this paper, however, are high-level patterns and work on providing the quality of security in software architecture.
The high point of the seminar was that the author was present to take questions. Usually in the meetings, sometimes we have to scratch our head trying to figure what the author was trying to mean. Here, those issues were non-existent.
The main thing that the group would have liked to see in the paper was a bit more discussion about operating system related issue. The author admitted that he did some hand-waving on some issues. However, the patterns presented in the paper are all high-level patterns (architectural patterns) and the fact that low and middle-level features were not getting discussed is not surprising. The author is now involved in the security patterns book project from Wiley publication with a band of other well-known software security specialists and that book tries to cover the whole gamut of security patterns. To me, the patterns discussed here are appropriate and co-related to cover a particular context, namely security architecture.
The software qmail and sendmail got a lot of attention when there were discussions about how security architecture becomes important. sendmail the popular Unix MTA has an array of failures associated with it. It was developed keeping functionality in mind and without proper domain knowledge about what problems may occur. qmail on the other hand is a much secure alternative because the development focus was on security. The point – security orientation is an important aspect of software design and design patterns help materializing that.
Nomenclature of patterns is considered a serious issue and the author was suggested a different and more appropriate name for his Checkpoint pattern.[The suggested name was Policy Enforcement Point]. The author took it into his stride along with other facts.
The vote did not work out this time. Because of the presence of the author, everyone went for an overwhelming ‘strong accept’ which may or may not have reflected the real mindset.