author: aman

Blog I - Part V - Day 05

The challenges faced while creating a secure software is quite straight, and so straight are the solutions. This blog covers the very two terms to tell about how to measure the realiability of a secure system.

Plus, after covering a lot of scenarios, I will try to connect the dots for you people, to be able to comprehend the further blogs.

It gotta be a little boring one. But very essential.

In this micro-blog

  • What am I talking about?
  • Why am I talking about it?
    • Have you heard before? (The “goto fail;”, Heartbeat, Meltdown, Spectre)
  • What the world is upto against such __ ?
  • Basic Challenges faced
  • Unimportant sounding complete terms
  • Motivation behind
Unimportant sounding complete terms

So, there could be two ways, either you take the code of the software you want to check vulnerability of, and check its path on various and varying input sets or just run the program under “instrumented” conditions and check for likely bugs. Simple to understand, take program and try to understand its structure and the critical conditions it can reach, or, make a sandbox(a testing environment to isolate your program from rest of the system), and test your program for faults.

The terms used for this are Static and Dynamic,

  • Static analysis
    • Inspect code or run automated method to find errors or gain confidence about their absence
    • Try to aggregate the program behavior over a large number of paths without enumerating them explicitly
  • Dynamic analysis
    • Run code, possibly under instrumented conditions, to see if there are likely problems
    • Enumerate paths but avoid redundant ones

The two following terms, tells about the measure of a “should be used”, software analysers. There is always a great deal of researches in the Universities across the globe, to create the better software.

Soundness “Sound for reporting correctness”

or equivalently There is a bug  Analysis finds a bug Completeness “Complete for reporting correctness”

Property Definition
Soundness Analysis says no bugs -> No bugs
Completeness No bugs -> Analysis says no bugs

In a funny manner, it simply means that if a program analyser says that a program has no bugs, it “actually doesn’t have any bug”. And, completeness is when if there are “NO BUGS”, the program analyser should be able to tell that there are no bugs.

Think for a while, how these terms are so powerful, in context of an efficient program analyser.

During my research at IITK, Dr Pramod took me to work on a FUZZER, which is simply a Dynamic kind of software analyser, which fuzz(input) the software program with random inputs, and checks for its failure in accordance with the INVARIANTS(specifications) provided.

a lot more to cover, before ending this major blog, and starting with the new one.

See ya.. Cheers.!!