Computer Systems Security: Winter 2018 Assignment 3: Difference between revisions
No edit summary |
No edit summary |
||
Line 14: | Line 14: | ||
# Download the ISO (say, from a distribution mirror) and compute its hash using SHA-1 or SHA-256. Then compare it to the hash available from the main distribution website. To get a further guarantee, verify the hash file using a digital signature. (Normally, wherever you have the list of hashes, you also have a detached signature for the hash list file.) For example, see [http://cdimage.ubuntu.com/ubuntu/releases/17.10.1/release/SHA256SUMS] for the Ubuntu server hashes. The [https://help.ubuntu.com/community/VerifyIsoHowto Ubuntu Verify ISO Howto] explains the process in some detail. Note for this to work, we have to assume that 1) the obtained hash is authentic (either because we downloaded it from a trusted source or because it was signed by a trusted key) and 2) the hash function has not been compromised. #2 is a pretty safe bet nowadays for SHA256, is probably okay for SHA1 (because breaks have been found but they are still very computationally expensive), and is highly suspect for MD5 (as MD5 collisions are trivial to create). | # Download the ISO (say, from a distribution mirror) and compute its hash using SHA-1 or SHA-256. Then compare it to the hash available from the main distribution website. To get a further guarantee, verify the hash file using a digital signature. (Normally, wherever you have the list of hashes, you also have a detached signature for the hash list file.) For example, see [http://cdimage.ubuntu.com/ubuntu/releases/17.10.1/release/SHA256SUMS] for the Ubuntu server hashes. The [https://help.ubuntu.com/community/VerifyIsoHowto Ubuntu Verify ISO Howto] explains the process in some detail. Note for this to work, we have to assume that 1) the obtained hash is authentic (either because we downloaded it from a trusted source or because it was signed by a trusted key) and 2) the hash function has not been compromised. #2 is a pretty safe bet nowadays for SHA256, is probably okay for SHA1 (because breaks have been found but they are still very computationally expensive), and is highly suspect for MD5 (as MD5 collisions are trivial to create). | ||
# There are many possible answers for this question. Correct answers should focus on the limitations of signature and specification-based intrusion detection, specifically how signatures are a black list and specifications are a white list. Anomaly detection can detect attacks that wouldn't be listed on a black list and would be included on a white list. For example, an HR employee may be authorized to look at the address and tax identification number of specific individuals as part mailing tax forms. That same employee is not authorized to access addresses and tax identification numbers for other purposes (e.g., to commit identity theft). With standard intrusion detection or access control, the employee would be allowed to access this sensitive information at any time. An anomaly-based intrusion detection system, however, could detect that this information is being access at an unusual time or in an unusual way (e.g., from an unusual location). | # There are many possible answers for this question. Correct answers should focus on the limitations of signature and specification-based intrusion detection, specifically how signatures are a black list and specifications are a white list. Anomaly detection can detect attacks that wouldn't be listed on a black list and would be included on a white list. For example, an HR employee may be authorized to look at the address and tax identification number of specific individuals as part mailing tax forms. That same employee is not authorized to access addresses and tax identification numbers for other purposes (e.g., to commit identity theft). With standard intrusion detection or access control, the employee would be allowed to access this sensitive information at any time. An anomaly-based intrusion detection system, however, could detect that this information is being access at an unusual time or in an unusual way (e.g., from an unusual location). | ||
# Both intrusion detection systems and anti-malware systems can detect malware. IDSs detect them by observing the signatures of malware (e.g, patterns in network packets) or by noting the deviations in behavior they cause (violating either specification or learned models of behavior). Anti-malware systems use code and behavioral signatures analogous to the signatures of anti-malware systems; however, anti-malware systems generally apply these rules after unpacking and de-obfuscating code. They also can apply the signatures to behavior observed in sandboxed environments. | |||
# |
Revision as of 16:27, 31 March 2018
Due: March 26, 2018 by the start of class.
Questions
- [2] How can you check the integrity and authenticity of a downloaded ISO image of a Linux distribution? Explain what you must assume for both integrity and authenticity to be assured.
- [2] Describe an attack (and associated context) that could be detected using an anomaly-based intrusion detection system but would normally be missed by both specification and signature-based intrusion detection systems.
- [2] How are intrusion detection system similar to anti-malware systems? How can they be different?
- [1] What is one significant reason that most currently used intrusion detection systems use signatures rather than other approaches?
- [2] Why are insider attacks potentially more damaging than outsider attacks? Explain using a simple example.
- [1] What is a concept from this class that you find confusing or hard to understand? Please explain briefly the difficulty you are having.
Solutions
- Download the ISO (say, from a distribution mirror) and compute its hash using SHA-1 or SHA-256. Then compare it to the hash available from the main distribution website. To get a further guarantee, verify the hash file using a digital signature. (Normally, wherever you have the list of hashes, you also have a detached signature for the hash list file.) For example, see [1] for the Ubuntu server hashes. The Ubuntu Verify ISO Howto explains the process in some detail. Note for this to work, we have to assume that 1) the obtained hash is authentic (either because we downloaded it from a trusted source or because it was signed by a trusted key) and 2) the hash function has not been compromised. #2 is a pretty safe bet nowadays for SHA256, is probably okay for SHA1 (because breaks have been found but they are still very computationally expensive), and is highly suspect for MD5 (as MD5 collisions are trivial to create).
- There are many possible answers for this question. Correct answers should focus on the limitations of signature and specification-based intrusion detection, specifically how signatures are a black list and specifications are a white list. Anomaly detection can detect attacks that wouldn't be listed on a black list and would be included on a white list. For example, an HR employee may be authorized to look at the address and tax identification number of specific individuals as part mailing tax forms. That same employee is not authorized to access addresses and tax identification numbers for other purposes (e.g., to commit identity theft). With standard intrusion detection or access control, the employee would be allowed to access this sensitive information at any time. An anomaly-based intrusion detection system, however, could detect that this information is being access at an unusual time or in an unusual way (e.g., from an unusual location).
- Both intrusion detection systems and anti-malware systems can detect malware. IDSs detect them by observing the signatures of malware (e.g, patterns in network packets) or by noting the deviations in behavior they cause (violating either specification or learned models of behavior). Anti-malware systems use code and behavioral signatures analogous to the signatures of anti-malware systems; however, anti-malware systems generally apply these rules after unpacking and de-obfuscating code. They also can apply the signatures to behavior observed in sandboxed environments.