4 ms·

One-time audit is great, but continuous auditing is also crucial. There are three kinds of vulnerabilities I can think of: * software bugs * design flaw * ba

by yeukhon 10y ago

One-time audit is great, but continuous auditing is also crucial. There are three kinds of vulnerabilities I can think of: * software bugs * design flaw * backdoor First could be detected using fuzzer, static analysis and proof reader. The second and third, unclear to me how could be found intelligently without human code review. Perhaps https://news.ycombinator.com/item?id=12236394 https://news.ycombinator.com/item?id=12236394 is relevant? Anyone?

unboxed_type 10y ago
You could check design flaws using model checking and/or rigor formal verification process. I think it is what they meant under 'advanced mathematics' term.
wepple 10y ago
> First could be detected using fuzzer, static analysis and proof reader. I respectfully disagree; I don't think we're truly at the point where we can rely upon these techniques over human code review.
- bluGill 10y ago
  If you are relying on anything alone you are a fool. If you are not using the above as part of your solution you are a fool. Each of the above will consistently find certain types of errors. The above tools do not "let their mind wonder", get bored, or any of the other things that happen to humans. When you as a human find an error it is worth asking if you can modify one of the above tools to find that class of errors so that you can be sure all cases were caught. Unfortunately most of the time we cannot yet (generally because the number of false positives is too high - I'm hoping for research to improve this)
  - wepple 10y ago
    I agree with everything you've said. Automation and tooling where it excels, humans where necessary and for oversight. My comment was largely around the fact that parent comment seemed to say "software bugs have been solved by tools, but design problems need humans". I think design/backdoor/crypto bugs may be more (or entirely) depending on manual audit, but it's dangerous to suggest software bugs can be fully automated away. Perhaps the parent comment was suggesting we should look to more software solutions to backdoor/design flaws? that's an interesting thought exercise.
nickpsecurity 10y ago
There's always human review. Should always be human review. The real goal is to reduce the amount of stuff we have to trust whether human or machine. High-assurance security does it as follows: 1. Formal specs of what it's doing in terms of features and security where there's no ambiguity. 2. Formal specs of how it does that. 3. Formal, machine-checked proof that the how embodies the what. 4. Formal proof or even extraction of implementation. These techniques can go down to machine code or gates now. 5. Covert channel analysis to find any leaks in any of that. 6. Testing of every execution trace under a variety of inputs to show equivalence with formal model during success and failure! 7. Trustworthy distribution of above artifacts to both evaluators and users. 8. Optional, trustworthy checking of above artifacts on-site by users with diverse tooling. 9. On-site generation of system from distributed artifacts. 10. Proper guidance w/ automation where possible on secure initialization, configuration, maintenance, and termination. Shortest summary I can do of process that goes back to the 1980's for countering the three problems you mentioned. Many key issues have been grand slammed out by tooling and checklists. Others are still evolving with mixed success. Clever attackers might always embed new backdoor you don't see. Plus, specs, tests, or key tools might be wrong. Hence, human review of each of the above by many smart minds is the most important assurance activity. EDIT: I should note that, while it looks waterfall process, it can and probably should be done a mix of top-down & bottom-up development. Important thing is you can link various pieces together for believable assurance argument.

by yeukhon 10y ago

unboxed_type 10y ago

You could check design flaws using model checking and/or rigor formal verification process. I think it is what they meant under 'advanced mathematics' term.

wepple 10y ago

> First could be detected using fuzzer, static analysis and proof reader. I respectfully disagree; I don't think we're truly at the point where we can rely upon these techniques over human code review.

bluGill 10y ago
If you are relying on anything alone you are a fool. If you are not using the above as part of your solution you are a fool. Each of the above will consistently find certain types of errors. The above tools do not "let their mind wonder", get bored, or any of the other things that happen to humans. When you as a human find an error it is worth asking if you can modify one of the above tools to find that class of errors so that you can be sure all cases were caught. Unfortunately most of the time we cannot yet (generally because the number of false positives is too high - I'm hoping for research to improve this)
- wepple 10y ago
  I agree with everything you've said. Automation and tooling where it excels, humans where necessary and for oversight. My comment was largely around the fact that parent comment seemed to say "software bugs have been solved by tools, but design problems need humans". I think design/backdoor/crypto bugs may be more (or entirely) depending on manual audit, but it's dangerous to suggest software bugs can be fully automated away. Perhaps the parent comment was suggesting we should look to more software solutions to backdoor/design flaws? that's an interesting thought exercise.

nickpsecurity 10y ago

There's always human review. Should always be human review. The real goal is to reduce the amount of stuff we have to trust whether human or machine. High-assurance security does it as follows: 1. Formal specs of what it's doing in terms of features and security where there's no ambiguity. 2. Formal specs of how it does that. 3. Formal, machine-checked proof that the how embodies the what. 4. Formal proof or even extraction of implementation. These techniques can go down to machine code or gates now. 5. Covert channel analysis to find any leaks in any of that. 6. Testing of every execution trace under a variety of inputs to show equivalence with formal model during success and failure! 7. Trustworthy distribution of above artifacts to both evaluators and users. 8. Optional, trustworthy checking of above artifacts on-site by users with diverse tooling. 9. On-site generation of system from distributed artifacts. 10. Proper guidance w/ automation where possible on secure initialization, configuration, maintenance, and termination. Shortest summary I can do of process that goes back to the 1980's for countering the three problems you mentioned. Many key issues have been grand slammed out by tooling and checklists. Others are still evolving with mixed success. Clever attackers might always embed new backdoor you don't see. Plus, specs, tests, or key tools might be wrong. Hence, human review of each of the above by many smart minds is the most important assurance activity. EDIT: I should note that, while it looks waterfall process, it can and probably should be done a mix of top-down & bottom-up development. Important thing is you can link various pieces together for believable assurance argument.