Countermeasures

• We already discussed "User Vigilance" on page 197.
  • Even though I made fun of some of it, the section is worth a read.
  • And you should practice the techniques listed there.
• Virus Detectors
  • These scan code, especially in locations known to harbor viruses.
  • They look for known virus patterns.
  • But
    • They only look for patterns that are known.
      • New viruses escape detection until their patterns are
        • Recognized
        • Added to the list of signatures
        • Distributed to machines running the virus checkers.
      • And this gives the new virus developer hours to days.
    • The patterns are fixed
      • Small patterns are easy.
      • But longer patterns can contain more variation.
      • And can have random internal mutation to avoid virus detectors.
  • Symantec (Norton) announced in 2014 that antivirus technology is dead ((Summary, not actual article)
    • Only effective against 45% of viruses.
    • But the book authors note
      • 45% is still better than 0.
      • And they are selling additional monitoring and professional assistance.
  • Code analysis
    • This is much more difficult.
    • Remember, we are looking at machine code, not high level code.
      • So the code under examination is much less meaningful.
      • And the code must be examined in a line by line manner.
      • And this might have to be reconstructed from a memory dump.
    • The book points out, this is equivalent to working with a microscope and tweezers.
    • And is very difficult work that depends heavily on human ingenuity
  • Storage in files
    • Another method of detecting a virus is attempting to find where it is stored in the file.
• Countermeasures for developers
  • Software engineering
    • Write code that is
      • written in small, self-contained units.
    • This limits the impact from other components failing.
    • They say that you should write modules that are
      • Small
      • Single purpose
      • Simple
      • Independent
    • This assists with
      • Maintenance
      • Understandability
      • Reuse
      • Correctness
      • Testing.
    • Modules should be highly cohesive
      • They have a logical and function reason for being grouped.
      • The single purpose.
    • Coupling describes how the units depend on each other.
      • Ideally, loose coupling is better than tight coupling
    • In the end, software should employ the following concepts
      • Encapsulation: hide the implementation details
      • Information Hiding: Keep internal data internal.
      • Mutual Suspicion: Trust other program elements as little as possible. Even stronger for other programs.
      • Confinement: Limit the availability of resources and data available to programs. This should be just what they need.
      • Simplicity: Everyone involved should be able to understand what is happening.
        • Design through implementation.
        • Tricky code is broken code.
      • Diversity
        • A single point of failure is bad.
        • Multiple vendors, multiple environments.
        • Heartbleed
          • A buffer over-read flaw in software.
          • In the OpenSSL library
          • Allowed the theft of private keys, cookies and passwords.
          • The book reports that over 66% of the sites using ssl were using OpenSSL.
  • Testing
    • Code
      • They describe various forms of testing.
      • But the real problem is for cybersecurity we need to test "The system will do this, and nothing more".
        • The first part is hard.
        • The second part is very hard.
    • They list "ingredients" for testing systems
      • Product expertise: You need to understand the product being tested.
      • Coverage: You must test everything, but you probably can't do this.
      • Risk Analysis: What are the most critical pieces to test and what can go seriously wrong?
      • Domain expertise: You need to know the background of the product. (Accounting techniques, scientific facts, ... ) related to the product.
      • Common vocabulary: You need to be able to talk to the users and the developers.
      • Variation: You need to explore beyond the expected.
      • Boundaries: You can't test forever, decide what the limits are.
    • Finally, testing
      • Only shows that bugs exist, it can not show that they do not exist.
      • Becomes more difficult, or impossible, in larger more complex environments.
      • Needs to be comprehensive, both white and black box, both internal structure and interactions.