What If They Can Read Our Redactions?

What If They Can Read Our Redactions?

The New Yorker has a fascinating article about technology advances being made to un-redact classified text from government documents.

Typically, classified material is redacted from disclosed documents with black bars that are technologically “burnt” into the document.

With the black bars, you are not supposed to be able to see/read what is behind it because of the sensitivity of it.

But what if our adversaries have the technology to un-redact or un-burn and autocomplete the words behind those black lines and see what it actually says underneath?

Our secrets would be exposed! Our sensitive assets put at jeopardy!

Already a Columbia University professor is working on a Declassification Engine that uses machine learning and natural language processing to determine semantic patterns that could give the ability “to predict content of redacted text” based on the words and context around them.

In the case, declassified information in the document is used in aggregate to “piece together” or uncover the material that is blacked out.

In another case prior, a doctoral candidate at Dublin City University in 2004, used “document-analysis technologies” to decrypt critical information related to 9/11.

This was done by also using syntax or structure and estimating the size of the word blacked out and then using automation to run through dictionary words to see if it would fit along with another “dictionary-reading program” to filter the result set to the likely missing word(s).

The point here is that with the right technology redacted text can be un-redacted.

Will our adversaries (or even allies) soon be able to do this, or perhaps, someone out there has already cracked this nut and our secrets are revealed?

(Source Photo: here with attribution to Newspaper Club)

>Common Language for Enterprise Architecture

>

What happens when one set of enterprise architects can’t read another’s enterprise architecture “artifacts”?

This may sound ridiculous, but this is a very real problem at the Department of Defense (DoD) and at many other agencies.

Government Computer News, 1 February 2010, has an article on “Primitives and the Future of SOA” about how “DoD looks to develop a common vocabulary to improve system design.”

Dennis Wisnosky, the chief technical officer at the DoD Business Transformation Agency came face-to-face with this problem:

“We were building a business enterprise architecture when the whole team changed because the contract [that the work was being performed under] was won by different people…The new company came in and, all of a sudden, their people had different ideas for how the architecture should be built…Their way might have been a good way, but we had already invested hundreds of millions of dollars in another way, and it seemed to be a wiser course of business action to get these new people to learn the old way.”

Mr. Wisnosky tackled the problem head-on:

Like the periodic table of 117 core elements that make up everything in our world, Mr. Wisnosky set out to build the DoD architecture using a set of primitives or basic building blocks. “Primitives are a standard set of viewing elements and associated symbols” based in DoD’s case on the Business Process Modeling Notation (BPMN)”—a graphical representation for processes in a workflow. Armed with the set of primitives, DoD was able to get “the business process architecture, so that they are described in a way that the meaning of this architecture…is absolutely clear to everyone.”

Wisnosky aptly compared using a common language (or set of primitives) for EA, so everyone could read and understand it, regardless of their particular EA methodology to how musicians anywhere in the world can read standard music notation and similarly how electrical engineers can read electrical diagrams based on standards symbols.

This is a big step for EA, where traditional architecture artifacts are not as user-centric as they should be and often leave their readers/audience questioning the purpose and message intended. In contrast, the use of a common EA vocabulary and set of symbols is right in line with developing a user-centric enterprise architecture that is easy for users to understand and apply, because once you know the standard set of primitives you can read and understand the architecture better than an architecture based on a proprietary or ever changing vocabulary.

As Wisnosky points out, primitives are also a nice fit with Service Oriented Architecture, because you can use primitives or patterns of primitives to represent standard business processes and these can be used over and over again for the same services that are needed throughout the business.

This use of primitives for business process notation is consistent with the use of the National Information Exchange Model (NIEM) for information notation. “NIEM enables information sharing, focusing on information exchanged among organizations as part of their current or intended business practices. The NIEM exchange development methodology results in a common semantic understanding among participating organizations and data formatted in a semantically consistent manner. NIEM will standardize content (actual data exchange standards), provide tools, and managed processes.”

While, we need to leave a certain amount of flexibility in EA for architects to apply their trade to meet specific agency requirements, there is a huge benefit to standardizing on a common vocabulary, so architects can speak the same language. This concept is all the better when the language and design methodology selected for EA is simple and clear so that even non-EA’s (our regular business and IT people) can read and understand the architecture.

Building EA with primitives and clear and simple vocabulary and design represents a user-centric EA moment that I for one, applaud loudly. Another way to say this is that an EA without primitives is a primitive EA.