Good Security Practices for Programming

This is the one of a series of posts on "Good Data Processing Security Practices."  The context for the series can be found here.  The following practices and controls are for programming, the processes, including management, by which programs are produced. 


Procedures should exist for enforcing adherence to rules. standards and
conventions (see Good Practice for Programs). Such procedures should be
sufficiently rigorous to make variances and anomalies obvious to management.

Procedures should exist for enforcing separation of duties and involvement
of multiple people (see Good Practice for Programmers).

Procedures should exist for requiring and recording the approval and
authorization of user and development management. These may be forms
or other procedures external to the system. or transactions or procedures
internal to it which can be invoked only by the designated managers.

Procedures should exist for maintaining the integrity of module and version
names. (see good practice for program libraries).

Procedures should exist for maintaining a record of the creation and
modification of all programs, The record should contain the content of the
change and references to the programmers. the date and time and the
process used.

Procedures should exist for reconciling the program to the specification.
These should include tests. independent review,s and structured walk-throughs.

Procedures should exist for maintaining a record of the results of all test.
review, and walk-through results.

Procedures should exist for requiring and recording the acceptance of user
management.

Procedures should exist for reconciling resource consumed (e.g., programmer
time. computer time) with expectation.


These procedures can effectively be built into the forms. editors. compilers.
library managers. and test drivers and other tools used by programmers, librarians. and
management.

The Obama White House Response to Internet Vulnerabilities

The White House has responded to recent reports that the NSA knew about and exploited the Heartbleed vulnerability rather than fixing it.  While denying the report, the White House pointed out that the choice is not quite so obvious as it might seem.  They assert that the narrow intelligence or investigative advantage from the exploitation of the vulnerability might trump the broader security advantage of fixing it.

"Governing is about making (often difficult) choices."

This is a particularly troubling space. There has been a dramatic loss in public trust and confidence in government over the last two administrations. "National Security" and "investigative necessity" have contributed to that loss.  Not only do they cover a multitude of sins, they are often used for that purpose. Finally, neither the NSA nor the FBI tell the White House everything they know or do. Indeed, in pursuit of "plausible deniability," both agencies often keep their own leadership in the dark.

We are not going to,reform these agencies as long as the current leadership remains in place. While Alexander has retired, Brennan, Clapper, and Holder would be justified in concluding that they are doing the right thing and ought to do it harder.

I do not advocate public disclosure of vulnerabilities. "Heartbleed" and the recent Internet Explorer vulnerability demonstrate that the angst surrounding such disclosure is often more costly than the risk of the vulnerability. However, quiet and immediate notification of the developers, distributors, and those others best able to,close it, should be the default. Indeed, many of these vulnerabilities are so pervasive that even the best we can hope for in closing them will leave a big window in which the government can exploit them for its other purposes, legitimate and otherwise.