
Dramatically Reducing Software Vulnerabilities [pdf] - Dowwie
http://csrc.nist.gov/publications/drafts/nistir-8151/nistir8151_draft.pdf
======
gwu78
Of the many recurring stupid ideas for startups I have had is a software
company that does not write code. Instead it edits and removes code. This has
been called "negative coding."

Few people write small programs anymore. UNIX, the OS that runs the internet
and on which the "cloud" depends, is a time-capsule full of small programs.
What this might mean is left as an exercise for the reader.

Today, large programs are celebrated without question.

Gratuitous complexity can be disguised as "productivity" and pitched as value
creation. At the very least it can be a source of fascination for futurists.
Any liabilities created in the process can be easily explained away.

Among the many things that can be done with this output, one of them to is to
make small programs from the larger ones. As far as I can tell, this is not
being done.

For myself, I have taken large, open source programs and gutted all the
needless features in order to produce the small programs I want.

My goal is less complexity. Simplicity is a loaded term. For myself, this
process of incrementally reducing complexity "creates value". It is an
intellectual exercise, there is a sense of productivity, and yet almost no
code is written.

Software companies are full of developers who cut, paste and compile. Today
many of them are working with open sourced code. The software company I aim to
start is comprised of "programmers" who also work with such open sourced code,
they only cut and compile.

EDIT: Whenever I see the "Who's hiring" thread I always wish I could put in an
entry for this. The vision I have is a group of "early employees" with day
jobs. Absent connections and name dropping no VC would ever fund this. No one
will be paid to do this "negative coding" work until we secure our first
government or Fortune 100 contract and they see the results. And even then I
could not guarantee the results would be appropriately valued. But were this
fictional company to succeed, those early employees could claim they were an
integral part of a monumental paradigm shift.

EDIT 2: The fictional company does negative coding on _single programs_ to
reduce them in size or to break them up into smaller programs and is not
limited to the embedded market or driven by resource constraints. Selecting
parts of an open source OS distribution to create a new distribution is a
different idea and of course many companies have been doing that for many
years.

~~~
newman314
I even have a tag line for you: "Do better with less"

~~~
guessmyname
Ironically, that's the jQuery slogan [1]: Write less, do more

[1] [https://jquery.com/](https://jquery.com/)

~~~
userbinator
...while relying on more.

Using frameworks/libraries often can reduce the amount of code one has to
write to perform a certain task, but it also can greatly increase the _total_
complexity of the system. The OP is talking about reducing total complexity,
which may mean increasing local complexity slightly.

------
jwmullally
They should have pasted this diagram all over the document:
[https://en.wikipedia.org/wiki/Automata_theory](https://en.wikipedia.org/wiki/Automata_theory)

I'm disappointed that the "Formal Methods" section makes only a passing
reference to Finite State Machines. FSMs are arguably the easiest to
understand and use formal methodology, and probably the most prevalent.
Especially worth emphasizing given how difficult and opaque a lot of formal
methods remain to even people with 4 year CS bachelor degrees.

This old thread
[https://news.ycombinator.com/item?id=2949543](https://news.ycombinator.com/item?id=2949543)
had lots of interesting discussions on FSMs, particularly their current
widespread use in (sometimes mission-critical) embedded systems. An ongoing
problem seems to be a lack of robust first-class support for FSMs in every day
programming languages, which can limit debugging, static analysis, standard
tools etc.

Disclaimer: I know nothing about security or formal methods.

~~~
schoen
People making arguments about automata theory in security are often affiliated
with the LANGSEC program/project/movement.

[http://langsec.org/](http://langsec.org/)

There are lots of compelling ideas there (and LANGSEC researchers would tend
to agree that if a functionality can be implemented correctly as an FSM, that
would be a safer option).

A related phenomenon that people talk about is the unexpected Turing-
completeness (where people have been able to prove that so many different
parts of computing are Turing-complete -- things that were never _intended_ to
be programming languages). LANGSEC people and others refer to the negative
security implications of some of this as "weird machines", where you really
didn't want Turing-completeness but you got it by accident or by default
anyway, and it might be possible for an attacker who can corrupt control flow
or other kinds of state to then perform arbitrary operations. For security
people an example may be return-oriented programming, but there are evidently
others that can be thought of in the same way.

~~~
triplesec
This is fascinating. Do you have any examples or stories of such 'weird
machines'?

~~~
schoen
The concept is presented in

[http://www.langsec.org/papers/Bratus.pdf](http://www.langsec.org/papers/Bratus.pdf)

I think people have found a number of other, well, weird examples. I found

[https://www.usenix.org/conference/woot15/workshop-
program/pr...](https://www.usenix.org/conference/woot15/workshop-
program/presentation/rushanan)

via Google Scholar and there are more papers on this theme if you search for
"weird machines" there. It seems like a helpful way to think about this issue!

------
jefffoster
I wonder if this'll (or something like it) be the tipping point for
governments to introduce more regulations for software? We already have
regulations like PCI-DSS for dealing with payment card, maybe this'll end up
with regulations for dealing with security?

The conclusion suggests better specification, better testing and more
resilient architectures are the strategies that could make a difference.
Perhaps software engineering will have to agree on a set of "best" practices
that make security problems less likely to occur?

(typos)

~~~
jandrewrogers
Regulations in software tend to encourage compliance theater rather than
delivering the spirit of their intent in my experience. It isn't that
difficult to conform to regulations technically with an awful and careless
implementation, and I've seen it happen many times. It is "best effort", in
part because it is obscenely onerous or impossible to ensure some properties
in a strict sense.

Best practices also drift over time and vary with context. A challenge is that
there are very old, very large code bases where as a practical matter will
never be modernized because it is tantamount to a rewrite, with all of the bug
creation and cost implied.

Robust software is definitely possible today even in languages like C++, but
the development process for software that rarely fails isn't that compatible
with the popular "fast iteration" development model nor the current computer
science skills of most software engineers.

~~~
throwaway729
All of this is true, which is why effective policy interventions would punish
bad outcomes, not prescribe methodology.

Make bad software expensive and software quality will eventually increase.

~~~
ArkyBeagle
Bad software is already expensive. This is just poorly understood.

It's simply not fair to non-specialists to expect them to have a working
knowledge of how cost works in software.

~~~
throwaway729
Fines and vulnerability to class actions make the costs far more visible (and
increase it besides). If non-specialists routinely make bad decisions because
they don't understand how cost works, then the solution is to make the cost of
bad software dead obvious.

------
realkitkat
Although it does mention some risks of using 3rd party code/components in
passing under 'Understanding and Controlling Dependencies' (835-), I would
have expected them to make a stronger case for OWASP 2013-TOP10-A09: 'using
components with known vulnerabilities'[1] type of analysis. This applies to
almost any kind of modern application, not just web apps, but especially to
those written in native languages (C/C++/...) as we increasingly build our
applications by bringing in varying amounts of 3rd party code; open source or
commercial. Like traditional static code analysis, more or less mature tooling
exists in open source[2][3][4] and commercial capacity to perform static
binary and source code analysis to discover and track 'offending' 3rd party
code, which does make it practical to include this kind of analysis to
sdl/sdlc/devops workflows.

[1]
[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Compone...](https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities)
[2]
[http://www.binaryanalysis.org/en/home](http://www.binaryanalysis.org/en/home)
[3]
[https://www.owasp.org/index.php/OWASP_Dependency_Check](https://www.owasp.org/index.php/OWASP_Dependency_Check)
[4] [https://github.com/OWASP/SafeNuGet](https://github.com/OWASP/SafeNuGet)

------
gravypod
This is an interesting read. Despite this, I still cannot understand what a
Formal Method is.

It just says a method is 'proven'? How? Can someone please develop a piece of
software, document/video themselves doing it and explain what/why they are
doing parts of the project?

Basically walk a plebeian like me through making a program using formal
methods.

~~~
dwheeler
It's a slide deck, not a paper, but you might find this presentation from my
class helpful: [http://www.dwheeler.com/secure-class/presentations/Secure-
So...](http://www.dwheeler.com/secure-class/presentations/Secure-
Software-10-Formal-Methods.ppt)

A specific example of software developed using formal methods is Tokeneer:
[http://www.adacore.com/sparkpro/tokeneer/](http://www.adacore.com/sparkpro/tokeneer/)

There's a severe lack of publicly-worked examples. Most formal methods
applications are private, which inhibits improvement and use. I'm an advocate
for the creation of more "open proofs" where the tools, software being proved,
and the proofs are all available as open source software. If we had more open
proofs then it'd be a lot easier to understand, apply, and improve them.

~~~
retox
I believe the capability of ada to be formally proven was one of the reasons
it has seen use in defence and real-time systems.

~~~
nickpsecurity
Well, there was the mandate plus the language itself was better than others at
safety & programming in the large. The bigger reason, though, was that it was
systematically designed to eliminate error from the syntax to memory handling
to integrations. I mean, really thorough. Good description of all that in case
anyone wants to cherry-pick safety features for use in a simpler language.

[http://www.adacore.com/knowledge/technical-papers/safe-
and-s...](http://www.adacore.com/knowledge/technical-papers/safe-and-secure-
software-an-invitation-to-ada-2012/)

------
hyperion2010
I find this hilarious in light of what we know about the NSA. All solid
recommendations, but they are bandaids when compared to the sheer weight of
capital that is being misused by hoarding known vulns. Unfunded mandates are
fine for grandstanding.

~~~
schoen
I strongly oppose vulnerability hoarding, but I'd point out that if we don't
think it's easy to make political or cultural progress against it quickly, a
technical alternative to make people safer is actually finding ways to make
safe software. Plus, if "bugs are dense" advocates are right, we need major
qualitative improvements to software development in order to make much of an
impact (because they argue that different hoarders, or even different from-
scratch researchers, would primarily know about _different_ bugs).

So it's not unreasonable for NIST (which actually wants people to enjoy
computer security) to investigate what could be done in this area!

Edit: but it's true that it would be awesome to see government do something to
make these improvements actually happen -- and a research report probably
isn't that.

------
eganist
Incidentally, BSIMM 7
([https://www.bsimm.com/download/](https://www.bsimm.com/download/)) also came
out this month. Whereas BSIMM is descriptive and OpenSAMM
([http://www.opensamm.org/](http://www.opensamm.org/)) is prescriptive, I'm
curious to see how NIST tackles the secure development lifecycle.

------
roymurdock
_Goal:_

The goal of this report is to present a list of specific approaches that have
the potential to make a dramatic difference reducing vulnerabilities – by
stopping them before they occur, by finding them before they are exploited or
by reducing their impact.

 _Impetus:_

In response to the February 2016 Federal Cybersecurity Research and
Development Strategic Plan, NIST was asked to identify ways to dramatically
reduce software vulnerabilities. NIST worked with the software assurance
community to identify five promising approaches. This report presents some
background for each of the approaches along a summary statement of the
maturity of the approach and the rationale for why it might make a dramatic
difference. Further reading was provided for each approach. Hopefully other
approaches will be identified in the future.

 _Current Cybersecurity Approaches:_

1\. Formal Methods - how do you check your program while writing code? (static
analysis, model checkers, pragmas, model-based programming, and more recently
contracts)

2\. System Level Security - how do you partition components in a system?
(containers/hypervisors/virtualization with smart API calls)

3\. Additive Software Analysis - how do you analyze completed software to
check for problems? (expression and exchange standards, better IDE plugins,
advanced static analysis tools)

4\. Mature Development Standards - how can you modify and reuse tried and
tested code? (find, understand, learn, and combine the most relevant
frameworks)

5\. Moving Target Defense & Artificial Diversity - how can you minimize your
program's attack surface? (compile-time diversification, cryptography, OS
interface scrambling)

6\. On Metrics - how do we even define and measure a bug? ("There are far too
many proposed measures to evaluate or even list here. We can state that, as
alluded to above, metrics and measures should be firmly based on well-
established science and have a rational foundation in metrology to have the
greatest utility.")

 _Government Calls to Action:_

1\. Engage the research community (funding, contests and prizes,
infrastructure)

2\. Education & training for the dev community (school curriculum, training
programs)

3\. Policy, Legal, etc. (procurement standards, liability for failures,
insurance, standards, code repositories)

\---

In my opinion, this is a good piece to skim through as you'll probably come
across 1 or 2 practices/fields you hadn't heard of before. The recommendations
are (intentionally) vague.

Functional security is already taken very seriously in many life and safety-
critical industries. One potentially-troubling trend we are seeing in the
automotive/aerospace & defense industry is the consolidation of traditionally
disparate systems into heterogeneous, multicore processors in order to save on
hardware costs. These systems are relatively complex, and have the potential
to mix safety-critical environments (brakes, steering, acceleration ECUs
running an RTOS) with application environments (infotainment system running
Linux). Partitioning is big here. There are well-defined and accepted
standards for the majority of industrial automation, transportation, medical,
automotive, and aerospace & defense targeted systems.

Data security and privacy is not taken seriously by the majority of consumer
corporations (and even some government agencies), and won't be until the legal
repercussions of failing to protect client information are a serious threat to
the companies that build and maintain these databases and systems.

~~~
jwmullally
To back up your point, this was a great blog post on the fatal consequences of
failure in mission-critical car software: [http://embeddedgurus.com/state-
space/2014/02/are-we-shooting...](http://embeddedgurus.com/state-
space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/)

After reading one may think: Why the fuck is there _any_ dynamic memory
allocation (stack) going on there? Why isn't the car software implemented as
one big pre-allocated hierarchical state machine? You wouldn't expect such
execution dynamism in hard circuits or even FPGAs. But in any case I think
non-deterministic systems (especially complex CPUs+programs) should be
outlawed for such mission critical signal paths.

~~~
ArkyBeagle
You got me as to why this is considered remotely acceptable. This being said,
you sort-of need a stack for a context switch ( or possibly an ISR ) in many
RTOS offerings.

This also being said, I've had engineers react rather violently to the very
concept of FSMs. I can't say why that is.

------
nickpeterson
My affection for F# likes that ML and F# are explicitly mentioned in section
3.4.2 "Better Code".

