This talk is about the role of architecture in design. In some circles, software design is broken up into high-level design and low-level design. We saw this earlier when in iterative software development life cycles there was an overarching design phase at the beginning of the project. And then smaller design efforts as each iteration was executed. This latter, low-level design is what most of us know as design. High-level design is more commonly known as architecture. Now, depending on the project, architecture itself, can have different meanings. Classic computer architecture has to do with hardware, design of CPUS, memory, instruction sets, and so on. In the IT world, architecture concerns hardware and software infrastructures. What kinds of servers, operating systems, switches, routers and cabling do we buy? In a software project, architecture typically concerns technologies, policies and development concepts. As ethereal as these sound, they can be incredibly important in a project. An architecture decision might be whether a project uses Microsoft Access, MySQL, Oracle 12 or SQL Server 2016 for a project. An architecture decision might be whether JavaScript will be used or style sheets or just basic HTML, although HTML 5 is pretty fancy. The programming language might be an architectural decision, along with the specification of coding standards. Recall what was said a few lessons ago about choice of programming language. If a programming language requires a virtual machine to run it, you inherit all the security risks of the virtual machine. And my guess is that you don't know what those are, until they're patched. Architectural decisions might reach into other implementation areas too. We'll see later, one of the decisions make in the development of BitCoin, was that the hashing algorithm would be SHA256, Secure Hash 256, and that it would be applied twice. So that if a transaction record were hashed, the result of the hash would be hashed again. This decision strengthens the software against certain kinds of attacks. Architecture, in the software sense, can handle security problems in a way that design at the low-level can't do. Some years ago, I was working on a typical government waterfall project in a design project management role. At the time, the term nonfunctional was used to describe security requirements. The idea was that the security concerns were different from the functional requirements. Functional requirements specified what the software should do, and a security requirement said what the software shouldn't do. I found myself somewhat in disagreement with the classification of nonfunctional, however. This seemed to imply that the requirements were inert, inconsequential or not working. Of course, none of these were the case. I started to call these pervasive requirements in the documents I was writing. The security requirements were requirements that applied to all modules in the system, wherever they made sense. Most of these requirements, as you can guess, concerned user input. Leveraging the notion of pervasive, I created a set of screen controls which accepted unformatted user input. These included text boxes and grids, anything which would accept something a user typed. The controls check for anything that could cause SQL injection or could cause buffer overflows. The controls were extensively tested, and the architecture, or the high-level design documents for the project described when, where and how these controls should be used. Ultimately, the customer accepted the idea that verification of the pervasive security requirements did not require testing of each screen that accepted unformatted user input. Rather, a repeat of the verification tests of the controls, review of the design documents describing and indicating their use, plus a quick run of a software analysis tool, to show that no screens accepted unformatted user input without using these controls, constituted satisfaction of the requirement. Software projects using web servers or database servers may have to deal with hardware associated architectural issues. If you're building a website, and you'll have a potentially large number of users, you may have to make decisions about both web servers and database servers. For a number of reasons, including security, it is generally accepted that the database should not be on the Internet facing web server. And when you have a database server, do you need two, do you need failover, do you need replication? These are often decisions which need to be evaluated, perhaps prototyped, and made before the detailed characteristics of the design are flushed out. Of course, when specifying how servers, whether database or web or another sort would be linked together and configured. From the above examples, one can conclude that security is more a matter of architecture that it is of low-level design. Certainly you can still have secure software with a good high-level design or architecture, but having a well thought out architecture makes the lower-level design much simpler.
