ktiago/appseclab

Repository for the Applied Security Lab project at ETHZ

appseclab's Issues

Report

General review:

• 1) Use the security principles from the book to justify design decisions.

• 2) Carefully read the assignment and adhere to the template, regarding both
  the structure of the document and the content of each (sub-)section.

For example, for assets (2.1) name the asset and describe its desired
security properties. Do not list the method to achieve these. Do not just
list the asset without any property.

Also, for the threat evaluation, always name the threat source: who does
what to threaten the asset?

• 3) In your component description, explain the interfaces between the
  components!
  Do you, for example, use prepared statements, or other limits on the
  interfaces?
  Can you directly SSH to the next machine with full access? Does the
  webserver
  request services on behalf of a user (with credentials included)?

• 4) For your security design, consider

  • security of internal network
  • security of data in transit (i.e., on the network)
  • security of data at rest (i.e., stored on some machine)
  • authentication and session management
  • key management, including key setup
  • defenses against common web app vulnerabilities, e.g., XSS, CSRF
    Please discuss these points separately in Section 1.3.

  Also ensure that your security design is based on (or at least fits)
  the countermeasures proposed in your risk evaluation.

• 5) Use precise language and terminology.

  • Distinguish confidentiality, integrity, and security clearly.
    Note that security = confidentiality + integrity
    (regarding data at rest and in transit).
  • Do not just talk about "keys" or "a key", be specific!
    In particular:
    • An asymmetric key pair consists of a public key and a
      private key.
    • Differentiate certificate and associated private key clearly!
      A certificate binds a public key to a name by the CA's
      signature, the owner of the related private key can prove
      ownership (without revealing the private key).
    • Be clear that
      • The private key is NOT part of the certificate itself.
      • One does NOT sign messages with a certificate.
  • Clearly distinguish between the CA's and the user's private keys
    (why?).

Personal review:
General:

• - progress is ok, but you need to make both your design and the risk analysis more precise

System Characterization/Overview:

• - unclear from your Figure 1 whether grey components correspond to machines

• - also in text: assignment of components to machines remains unclear

Security Design

• - use security principles to justify your design!

• - important missing point: key management

• - some points are treated only very briefly

• - DMZ: firewall configuration does not seem to allow remote system administration

• Access control:

• - how do you control access to the different servers? (not only web server)

• - why not prevent SQL injection in the first place? (how?)

• - security of data at rest: where is sensitive data kept? (e.g., private keys and their backups?)

• - security of data in transit: communication only encrypted? what about authentication?

• Authentication subsection in Security Design (specifically mention signing of CRL)

Components:

• - strange: a client is a python script? what is it doing?

• - you should also describe the interfaces between components and other types of components, e.g., server machines (see assignment and template)

• - backup: how is this done? cron job? push or pull?

Assets:

• - fairly complete list of assets, except for information assets (see below)

• - missing: assets' security properties

• - do not describe the functionality offered by certain assets here (e.g., web server, CA server, DB server, 3-2-1 rule for backup); this belongs to Sect 1

• - Backup server: the backup tape is a different physical asset (possibly at a different location)

• - internet connectivity: could possibly be merged with edge router?

• - logical assets/internet connectivity: this is repeated from previous page

• - you do not necessarily need to precisely describe the state space of each asset

• - missing information assets: CRL, CA private keys? (why?) other private keys? (which?), backups, ...

• - availability: this is a security property, not an asset (it does appear as timeliness under "intangible assets")

Threat sources:

• - list looks quite complete

• - try to find a better name for "Adversaries", which is too generic (description is fine)

Risk definitions:

• - why does Medium Likelihood and High impact yield a High risk, while High likelihood and Medium impact yields a Medium risk; if this is intentional, then please justify it, as this is a deviation from the book.

Risk Analysis:

• - please number threats consecutively: 1, 2, 3, ...

• physical assets

• - #1: what about the other servers?

• - #2: "The server": which server?

• logical assets

• - risk evaluation is quite imprecise: please do distinguish different logical assets as they do not all have the same security properties, locations (e.g., DMZ vs intranet), ...

• - #1: data theft does not necessarily need physical access

• - #2: WAF should not be only countermeasure here..

• - #5: an "Internet user" is not a threat source

• person assets

• - why only one sysadmin?

• - #1: countermeasure seems unrealistic assuming that service interruptions are not acceptable

• - #3: "targeted hacking" is not a threat on a person

• - the threats 1, 2, 3 on lower half of page do not apply to a person, so do not belong here

• intangible goods

• - #2: unclear what countermeasure is and whether it helps

• Mention the user password situation (for convenience of the reviewing group)

• Add the fact that insecure SHA-1 is used for password hashing in the risk analysis

• Each asset (CACore, Web Server, etc.) should be analyzed seperately

• System Functionality chapter: Essentially step-by-step guiding how to use the system

• Information Asset (user data, certicifactes, private keys, CRL, server conf...)

• Make CRL downloadable and make sure its signed

• Password check is done in a timing-leaking manner (side-channel attack), either address or explain. Actually: Hash it, for equal time!

• Text about the SQL injection in Backdoor section

• Add DDOS in the risk analysis

• Be consistent whether client means the machine or the user

Things to do (besides the report)

• Do basic scans/network monitoring on all machines. Also autmated vuln tools (see book chapter?)