Security Principles for Software Architecture Design

追加: 2026-05-23

[00:00:02]hello uh students of csse 6400.

[00:00:07]today i'm gonna give you a guest lecture on security principles first of all i wanna thank the invitation from dr richard thomas my name is guan nombai and i am an academic in uq cyber security group in the school of itw the purpose for this guest lecture is to introduce you guys some security basics and also some security principles it's better that you take into consideration when you design your software i usually start this lecture with the you know virtualization of the increasing complexity of modern software so from this diagram you can find some well known complexity in terms of the lines of code of somewhere known software so i want to use the operating system as an example to show you this idea if you look at the operating system in a very very early state for example use nix version 1.0 it was invented probably 50 years ago or more than that so you can find it has a very small size which is like um definitely less than one million lines of code however if you look at the modern operating systems which nowadays you are using every day for example android which is a mobile operating system you can find these sizes between 10 million lines of code to 25 million lines of code and also the desktop os windows 7 has more than 25 million slides of code so the modern software you know is so complex that it's challenging to design and keep them safe keep them secure i want to use a few in famous cases to show this idea the first one is heartbleed not sure you guys heard of this one it was identified from ssrtis so ssltis is the encryption infrastructure for modern world basically every day when you build when you visit a website you can say https something like that https uq.edu so this https is uh means http over it says ntis that means they are probably the infrastructure of the modern web so this vulnerability was identified in 2014 from a third protocol of ssr and trs and it affects billions of servers it is so severe that some credentials like private keys of the web servers can be linked to the attacker and also another uh vulnerability called share shock so this vulnerability was identified from bash so if you guys use uh linux and when you interact with the os through command line actually you are using bash so share shock was identified in 2014 and actually later researchers found that this vulnerability stayed in bench since a very early version probably lasts for more than 10 years before it was identified by researchers and also here's an example of a modern company not sure whether you guys heard of this one equifax so this is a company who do the credit evaluation uh like when you apply a credit card from the bank and bankrupt delegate the credit evaluation to such companies so they own some credential data of the users like online transaction and purchase history so and so forth so you can find the data stored by them are very critical so in 2017 there was a data breach happened in this company so you can find immediately after that the stock price of this company dropped to nearly half of its original price so you can find how huge the security issue can bring you know financial loss to our corporation um this one um you know we had a lot of incidents like the password leakages from major websites like taobao yahoo so those companies fail to follow some best practices for example to encrypt the user password okay so they simply fail that and the security issues in those companies in the website of those companies may lead to password energy cage so the victims include you know million or even billions of the uh end users so among all those incidents or security issues if we look into the root cause of them we can find that almost all security failures are caused by vulnerabilities or marks or flaws in the software that you know bring us to think of some questions from the software engineering perspective like whether we can really you know design and verify the software so that the vulnerability the security issues can be prevented so i want to you know bring some consideration or some questions to all students in cssc6400 whether we can have security aware software design so we want to achieve like secure by design we're going to design a software in a secure way here i recommend you guys some materials you can follow including some books and also some vulnerability tracking system like backtrack or cbe which allow you guys to follow the current status of the you know vulnerabilities appeared in a while also i want to quickly uh talk about the sometimes i refer to it as different mindset of software engineers and security people so we know that software are developed to provide functionality or services so mostly we focus on how we can develop how we can complete our functionality in the software but the security people focus on another perspective like how we can regulate the excess of the crucial assert in the software i'll give you guys an example if we develop uh transaction system for a bank then software engineers will focus on you know how we can implement how we can design implement a transaction in efficiently and security people i think oh how we can make sure you know uh we can protect the security of the user account in that bank so different perspective and the first thing i want to discuss for today is some basics about security and when we you know talk about security probably cia is the most basic thing we will discuss so here c stands for confidentiality is about how we can you know prevent unauthorized people like attacker from knowing the secret the credentials of our system and integrity is about how we can prevent those unauthorized people from revised or modifying our information or software and availability stands for in how we can keep our service keep the functionality of our software available online for our authorized users so this is the cia trial so with this three uh basic concepts we will talk about how we can do you know software designed to provide confidentiality integrity and availability so the first one i want to talk about is the confidentiality design so when we design a system we're gonna protect those credential information uh we usually use two types of techniques masking and the cryptographic uh techniques so masking is used to you know prevent the data or credentials from learning by from being learned by the attacker when we display them on a screen or sometimes we print them [Music] and the form so if you guys you know look at these two screenshots you you can easily find you know a small secure for the left hand side one right because the password of this user is masked so that someone you know cannot learn it over their shoulder the second technique i want to talk about is cryptographic techniques they are usually more complex more systematic and sometimes also mathematical so they are used to assume actually confidentiality when the data is transmitted among parties different entities or the data is stored on the permanent storage so we'll talk about cryptographic algorithm cryptographic techniques really uh talk about two types of the cryptography the first one is called symmetric algorithm basically uh when you know this is first thing is the process of the you know cryptographer cryptographic algorithm so we have the plan tax which is the credential data we want to protect and those plain text will be encrypted so you can regard it as like not in code but after after some operation you cannot see you know the original contents of those plain text so this process is called encryption so the plain text will be encrypted into some uh you know seemingly random strings we call them cipher text so this cipher text will be decrypt which is the reverse of the encryption so the cipher text will be decrypted into the plain text so how we use them like if like if i want to send a message to to reach out to dr richard um and i know that the network is unsecured so what i would do is before i send to him i will encrypt the secret then send it over the network and when richard receives the ciphertext he were decrypted and received a secret and in the encryption decryption process we need one key to be involved which is called the secret key or sometimes we call them encryption key or decryption key so why we call this algorithms symmetric algorithm because these algorithms use only one key that means i and dr richard share the same key okay so many uh well-known algorithms can provide symmetric algorithms like ds3ds and also aes uh the other algorithm are symmetric algorithm so they have the same you know encryption and decryption concept the difference is when we encrypt we use a public key and when we decrypt we use a secret key so everyone owns a pair of public key and secret key so i own my pair and richard owes his pair so when i want to send a secret to richard i will use his public key to encrypt then he will after receive the cipher text he will use his own private key to decrypt and see the plain text so we we call this algorithms asymmetric algorithm because the encryption and decryption processes use different keys if you you guys heard of rsa it's a typical asymmetric algorithm so after the confidentiality you know normally we use masking or cryptography to achieve the confidentiality and now i want to talk about integrity design and for the integrity design we also have we also have two types of mechanism for you to consider when you desire software the first one is called hash and second one is called resource locking so hash is kind of mathematical functions that provide irreversible and also collision-free operations so irreversible means so the first of all first of all the hash function generates some length you know some short length of strings when given a long [Music] text like a big file even you know the image of your operating system as an input so the irreversible means you know you have that short lens text which is called hash value so if you have the hash value you cannot reverse it back to the original input okay and the collision frame means you know two original input cannot generate the same hash value so these are two properties of the hash function and if you heard of md5 5 6 they're all typical hash functions so how do you use hash function to protect the integrity of the data or your software i'll give you an example like i want to send data to recharge and i don't want everyone anyone to revise it to modify it during the transmission so what i do is i will calculate the hash value of this data and probably i will encrypt it with the public key of reacher only the hash value okay so i set both to to reach up and after we save this tool right the uh the data and also the encrypted hash value retrieval decrypt it to get the hash value and then calculate the hash value of the received data and check whether they are the same so because of the collision freeness you know two data cannot generate the same hash value if richard notified he has two hash value that means the data is modified during the transmission so this is one way or you can do the integrity protection and sometimes we can also use hash function to uh for the confidentiality design a very typical one i want to introduce here is because when you when you design a web you know sometimes you need to store the password of your users and one suggestion i will give to you is never store the password in plain text so still remember in a few slides ago right some big companies they store user password in plain text and once their system is compromised all the password will be linked to the attacker so what you should do is you should um you know once you get password then calculate the hash value of the password then you know remove just remove the password from your system and whenever you want to you know check the password of the user you just calculate the hash value and only check the hash value so never operate on the original password but still there is some issues here so i just leave it for you for your readings the basic idea is you know if two users have the same password and if you simply hash them then their hash value will be the same so what you can do is call you can use um sorted hashing probably you guys already heard of that so before you hash the password you add a user a unique sort maybe just concatenate you know the password with the sort then calculate the hash value and then you store the sorted hash value and in this way even two users share the same password you will have the different you have different sorted hash value and the other way you need to take into consideration integrity design is the resource locking so why do we need that is because of the existence of data risk i give example if you you know you design a transaction system for the bank then you need to adding some log to prevent the user from accessing their account from different two places right so what i can do a malicious user so let's say i have account 100 in my account and i log in my bank from mobile phone and then simultaneously log in again from the desktop so i will just transfer you know this 100 to alice and to bob i click them simultaneously okay so your software should guarantee that you know there must be only one transaction can happen okay otherwise the bank will lose money right so you need to take this into consideration when you're dealing with a concurrent system so the uh availability design basically we have three techniques replication fade over and scalability technique the replication you will know that we should prevent the single point of failure from happening so what we do is you know for particular functionality for a single functionality we can use maybe more than one component to provide it so in case one one dies you know you have still have others to provide the normal functionality to your user uh second one is failover that means you know when you design your software uh if you should design in a ways in in such a way that even one particular component or software or server or system fails you should have other components to replace it automatically okay so this is called failover and scalability techniques you can do vertical scaling like adding resources or horizontal scaling which is exactly the same as replication you know you just duplicate a component for multiple times okay so so far i already introduced you guys the concept of cia triad and also how we can do design for each you know for confidentiality we use masking and cryptography for integrity we can use hash and also log and for availability we have three techniques right the second part for today is some you know software design principles there are principles a high level thing and you should keep them in mind and you can derive rules you know from those principles later can guide your software design gonna introduce you uh four principles um and some rules you know under the principles the first one um favorite simplicity i wanna start with we're not sure whether you guys know this doctor or professor tony hawk so he is the inventor of famous hard logic and he wants to ring a word award because of his contribution in model checking and formal analysis of software of program so he is devoted to how to use mathematically to guarantee the correctness of software and i quote something from him you know there are two ways of constructing a software design one way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies and usually the first method is far more difficult so we know that right usually our software need to provide very complex functionality to the users and it's it's often not that easy to design the functionality design or software simple but try your best because for principle one i'm gonna discuss is called favorite simplicity so you should try to keep your software design so simple that it is obviously correct so this applies to you know the internal design like your data flow right and also the component within your software and also the external interface your software is going to provide interfaces for a third-party developer or for the end users so you should keep those external interface simple as well and also the implementation try to use some simple strategy to implement don't use you know large size of library in your implementation and also use some uh simple languages it's in there for you to implement them secure okay and some rules here you know when you consider the first principle the first rule is secured by default we know that some complete configurations and also usage choices in a system will affect the security of the system for example the length of the cryptographic keys and the choice of password and also to you know validate the inputs so the rule here is the default choice should be a secure one for example in your system in your software you should use you know by default secure key length for example uh sufficient uh bits for isa algorithm okay you don't let your user to select they will select something some unsecure configuration and also try not to have default password in your your system that i will give you examples to show why we shouldn't do this and you should um you know mandate your users to select a strong password okay so here is the example i want to talk about some data breach from healthcare.gov which is a u.s government website so user hackers attackers find that many users use by default password so they just simply you know never change the by default password the system give to them so the second rule here uh don't expect expert users so um when you design your software you should consider the mindset and ability of the lane users okay and also you know because of this you should favor simple user interfaces and those obvious choices should be secure one so for example you know your software need to pop up some alert window then you have yes or no right you really so you that there is one by default button and user will never read them you know they will just click the the the enter button so that that alert will go immediately that means you should put the secure you know the by default one a secure choice okay and another thing uh don't have your users make frequent security decisions uh like don't ask them to decide uh you know the um the plans of the password and also you know don't ask them to change that password too often because they were you know simply use up all their passwords and start using some some hard to remember once what they would do is they would just write it down and type on the monitor it's very insecure right okay so yeah the principle one um you know favor simplicity in your design and the principle two is trust with reluctance and the usually you know our system uh you know the whole system security work depends on the operat secure operations of its parks so you should try to you know reduce the trust of those small components so this includes you know reduce the parts of people needed to be trusted and also don't make unnecessary assumptions for example if you use a third-party library do not assume they are secure okay a very typical example we find is in the um those mobile applications like android applications so those applications will include advertisement advertisement library from third party to have them display advertisement on the screen of users so that they can you know the app developers can make money however many of the libraries are identified to collect user information okay so if you are such software developer do not assume the trustworthiness of the libraries you use and second if you are not a crypto expert do not design or implement your own algorithm because they are so so crucial you know you shouldn't have any security issue in the design implementation of such library so just use open source one or those mature implementation don't design or implement by your own and one concept i want to talk about because i talk about tcp trustee competent base so just now i mentioned right the whole system the security of the whole system depends on the part and the some part is crucial to the whole security of the system we call them tcp so a very um common example is operating system kernel so operating syst system kernel draws our high per village level right so we can put in some you know antivirus some process schedule memory management inside the os kernels that means if we trust them then based on that trust we can create so-called a chain of trust we trust them we can use them to validate the integrity the security of another component and based on that we can you know build the chair of trust another rule uh is called this privilege so do not give a part of the system or user more privileges than they need to do that job so a very typical example here is the mail program you know which sometimes need to include an editor so if you use some simple editor it's sufficient right because you only need for mail system you're only into typing words but if you use uh design you know i'm not very good designs you may include some rich functionality editors like bi or e-max they actually you know besides the text editing they can execute some code right so basically you give your editor more privilege and another example is you know when you design your software you may have different roles you know user administrator like lecturer student different laws so you should give the each doe just very restricted privilege you know sufficient for them to make to to you know to complete their jobs and no more than that okay because you don't know which law which people which user will abuse the privilege they have and also keep in mind trust is transitive if you trust something implicitly you trust that thing trusts so it's a chain of trust so like the previous email um the the this mail system uh client if you give the trust to the editor basically the trust editor right so what the editor do is to execute some extra code that means it's you who trust that abstract code is your electric code to be executed okay so keep this in mind in your design and also input validation so this is about the trust of the users um you don't know you know what input users will give basically uh sometimes you you ask the users to give you a valid email address right it should include a username and the domain name but you know some users maybe they're not malicious but they're just simply copied a long string from somewhere and put it into your input box and if you if for example if you use a small size buffer to host that string that it will cause the buffer overflow problem and also um sometimes you know the user were putting some code into the input box and if you don't validate that you just simply execute the code it will cause uh security issues so here the point is whenever you get input from your unless validate make sure the validity of the input and also to restrict the flow basically in your software you should try to restrain the flow of sensitive data within or basically let me reference it let me put it in this way so you should keep those critical data within your software try not to give it to some untrusted parties or give it to outside your external of your software so i give an example here like like a mission system at uq so it will receive the student application as a pdf files so this files regarding you know the applicants the privacy of the applicants so you should uk has a responsibility by law to protect those those data a very typical design for such system is it will allow the university administrators to download those files into that local computers but here there's problem right because you don't know whether the administrator will send it to others or if their computer get compromised those private information will be linked to the attacker as well so when you design such a system such as software a better way is you make the pdf within the software and provide only viewable interface to the user to the university administrator and don't allow them to download those data to their local computers and the last rule in the in the principle two is uh compartmentalization basically isolation idealization sorry isolation so the point here is in your software if two components have different security property you know one is very secure and the other need to handle a lot of user input or the other is you know developed by some new developer you know you don't trust them so the new way is to isolate them the way to isolate them is you can use you know process level so later i will give you an example or you can use machine level isolation so this is a process level basically uh in our browser that is a furious though nowadays we don't use flash play player anymore so but i seriously example because it gives a very design very good design about the isolation so the browser will use a flash player to pause to play the flash file and we know that the flash flare can include some malicious code so what the modern um web browser do like chrome what they do is they separate the execution of the you know the web page renderer and the flash player into two processes so even though you know the flash player is compromised it just affects that process because the other event crash the other still alive and another example is like when you design your software you need to use a few databases so what you can do is you put critical those crucial information in one database then put it behind the firewall right and the other database which includes only less critical data you put it with the web server okay so this kind of machine level isolation the point here is you can have different level isolations uh the third principle are called defense in-depth um so some rules here the first one security biodiversity basically uh for a single component try to put protect different types of security mechanism to protect it so a very well known example is the multi-factor authentication so you guys think about every day when you log into uq system you need to not only improve your password but also do you know authorized access from a mobile phone right so this is a two-factor authentication and second use community resources like some as i mentioned like some crypto libraries some open source libraries that have been uh used by widely you know by multiple developers because they also want to use you have some it's not you know for most formally verified secure but you have some confidence that those components those libraries ask you and also um you know try to virtual designs publicly open source your designs for other or just to your peers you know for them to examine your design um say whether that's security issues don't try to hide you know hide the information because attackers are smart they can always find some way to compromise the weakness in your software and also uh stay up to date on the recent swirls and research so like a few months ago we have the log 4g vulnerability is identified from attach server right so if you stay up to that you can immediately patch your vulnerable software and also here i list a few values you can get the latest information about the threats so the last principle i want to talk about is quite simple it's called monitoring and traceability the point is you know you also need to provide some some post incident forensics or investigation capability so you should design a software to you know conserve some log information and once a security issue some incidents happen you can rely on those logs to help you do some investigation so your law should simply uh include you know who does what to which object at what time and also if possible from where okay so keep those information um here is some uh you know some information you know i just google see what kind of typical design flaws in the software so if you look through them and basically most of them are covered by today's lecture so try your best to prevent those flaws and one typical one i want to talk about because this happens for a lot of non-security people they try to design and use and you know design implement and use that cryptographic algorithm and library which is really 22.6 okay so don't do that don't do that if you are not crypto experts don't invent don't even implement uh no one algorithm so for example if you only use aes you can find maybe tens of library open source libraries um so don't don't implement don't implement your own because there can be many security issues so still nowadays you know still open questions in a research community to guarantee the security of such libraries okay so basically this is what i talk about in today's guest lecture we cover some basic security basics like cia and how we can design and how we can make our software designed to provide cia and also i introduce four principles and for each principle we discuss several rules you can follow in your software design so that is all about today's lecture and um it's it's a pd i cannot give this lecture in the classroom or the word planned with richard um but because of the extreme weather and flooding in the brisbane era that didn't happen however if you have any questions if you have any interest you want to discuss with me on software security please just drop me an email or just ask richard to forward questions to me and thank you thank you all