Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

August 25, 2016

Developer Liability For Egregiously Poor Software

Filed under: Cybersecurity,NIST,Security — Patrick Durusau @ 3:37 pm

Earlier today, Cryptome tweeted:

cryptome-nist-460

I’m assuming that Cryptome added the highlighting to:

Software developers should be liable for egregiously poor software…

I don’t consider that suggestion to be, as Cryptome puts it:

NIST BS

Presently, there is no liability for software developers.

How’s that working out for you?

One indication of the “success” of the no liability model is Hackmageddon which relies on reported hacks and has hack timelines back to 2011.

A summary of the “success” of the no liability model is the Internet Security Threat Report, April 2016, by Symantec.

Both of those reviews rely on “reported” hacks, which omits those yet to be discovered (thinking NSA or Sony hacks).

By any reasonable measure of “success,” the no liability model is an absolute disaster.

We can debate how “egregious” software has to be for liability, but consider SQL injection attacks.

Here are five SQL injection “cheat sheets” and a listing of SQL injection scanners:

SQL Injection Cheat Sheet

MySQL SQL Injection Cheat Sheet

SQL Injection Prevention Cheat Sheet

Full SQL Injections Cheatsheet

SQL Injection Cheat Sheet & Tutorial: Vulnerabilities & How to Prevent SQL Injection Attacks

SQL Injection Scanner List

How difficult was that?

You have to be able to type “sql injection cheatsheet” and “sql injection scanner” into an internet search engine. (Rating: Easy)

Curious, is there a show of hands by developers who don’t think they can avoid SQL injection attacks?

FYI, if all developers avoided SQL injection attacks, it would kill the #1 cybersecurity hack on the top #10 list maintained by the Open Web Application Security Project.

We aren’t talking about obscure 0-day bugs that no one has ever seen. SQL injection was first noticed in 1998.

Liability for an 18 year old vulnerability isn’t too much to ask.

Yes?

PS: The NIST quote is from the Information Technology Laboratory Newsletter, September—October 2016, page 1.

April 14, 2015

Attribute-Based Access Control with a graph database [Topic Maps at NIST?]

Filed under: Cybersecurity,Graphs,Neo4j,NIST,Security,Subject Identity,Topic Maps — Patrick Durusau @ 3:25 pm

Attribute-Based Access Control with a graph database by Robin Bramley.

From the post:

Traditional access control relies on the identity of a user, their role or their group memberships. This can become awkward to manage, particularly when other factors such as time of day, or network location come into play. These additional factors, or attributes, require a different approach, the US National Institute of Standards and Technology (NIST) have published a draft special paper (NIST 800-162) on Attribute-Based Access Control (ABAC).

This post, and the accompanying Graph Gist, explore the suitability of using a graph database to support policy decisions.

Before we dive into the detail, it’s probably worth mentioning that I saw the recent GraphGist on Entitlements and Access Control Management and that reminded me to publish my Attribute-Based Access Control GraphGist that I’d written some time ago, originally in a local instance having followed Stefan Armbruster’s post about using Docker for that very purpose.

Using a Property Graph, we can model attributes using relationships and/or properties. Fine-grained relationships without qualifier properties make patterns easier to spot in visualisations and are more performant. For the example provided in the gist, the attributes are defined using solely fine-grained relationships.

…

Graph visualization (and querying) of attribute-based access control.

I found this portion of the NIST draft particularly interesting:

…
There are characteristics or attributes of a subject such as name, date of birth, home address, training record, and job function that may, either individually or when combined, comprise a unique identity that distinguishes that person from all others. These characteristics are often called subject attributes. The term subject attributes is used consistently throughout this document.

In the course of a person’s life, he or she may work for different organizations, may act in different roles, and may inherit different privileges tied to those roles. The person may establish different personas for each organization or role and amass different attributes related to each persona. For example, an individual may work for Company A as a gate guard during the week and may work for Company B as a shift manager on the weekend. The subject attributes are different for each persona. Although trained and qualified as a Gate Guard for Company A, while operating in her Company B persona as a shift manager on the weekend she does not have the authority to perform as a Gate Guard for Company B.
…(emphasis in the original)

Clearly NIST recognizes that subjects, at least in the sense of people, are identified by a set of “subject attributes” that uniquely identify that subject. It doesn’t seem like much of a leap to recognize that for other subjects, including the attributes used to identify subjects.

I don’t know what other US government agencies have similar language but it sounds like a starting point for a robust discussion of topic maps and their advantages.

Yes?

April 12, 2015

NIST Big Data interoperability Framework (Comments Wanted!)

Filed under: BigData,NIST — Patrick Durusau @ 3:49 pm

NIST Big Data interoperability Framework

The NIST Big Data Public Working Group (NBD-PWG) is seeking your comments on drafts of its first seven (7) deliverables. Comments are due by May 21, 2015.

NIST Big Data Definitions & Taxonomies Subgroup
1. M0392: Draft SP 1500-1 — Volume 1: Definitions
2. M0393: Draft SP 1500-2 — Volume 2: Taxonomies

NIST Big Data Use Case & Requirements Subgroup
3. M0394: Draft SP 1500-3 — Volume 3: Use Case & Requirements (See Use Cases Lising)

NIST Big Data Security & Privacy Subgroup
4. M0395: Draft SP 1500-4 — Volume 4: Security and Privacy

NIST Big Data Reference Architecture Subgroup
5. M0396: Draft SP 1500-5 — Volume 5: Architectures White Paper Survey
6. M0397: Draft SP 1500-6 — Volume 6: Reference Architecture

NIST Big Data Technology Roadmap Subgroup
7. M0398: Draft SP 1500-7 — Volume 7: Standards Roadmap

You can participate too:

Big Data professionals continue to be welcome to join the NBD-PWG to help craft the work contained in the volumes of the NIST Big Data Interoperability Framework. Please register to join our effort.

See the webpage for details on submitting comments. Or contact me if you want assistance in preparing and submitting comments.

January 27, 2015

NIST developing database to help advance forensics

Filed under: Government,NIST — Patrick Durusau @ 5:33 pm

NIST developing database to help advance forensics by Greg Otto.

From the post:

While the National Institute of Standards and Technology has been spending a lot of time advancing the technology behind forensics, the agency can so only go so far. With all of the ways people can be identified, researchers still lack sufficient data that would allow them to further already existing technology.

To overcome that burden, NIST has been working on a catalog that would help the agency, academics and other interested parties discover data sets that will allow researchers to further their work. The Biometric and Forensic Research Database Catalog aims to be a one-stop shop for those looking to gather enough data or find better quality data for their projects.
…

Not all national agencies in the United States do a bad job. Some of them, NIST being among them, do very good jobs.

Take the Biometric and Forensic Research Database Catalog (BDbC) for example. Forensic data is hard to find and to cure that problem, NIST has created a curated data collection that is available for anyone to search online.

Perhaps the U.S. Axis of Surveillance (FBI/DEA/CIA/NSA, etc.) don’t understand the difference between a data vacuum cleaner and a librarian. Any fool can run a data vacuum cleaner, fortunately or the Axis of Surveillance would have no results at all.

Fortunately, Erica Firment can help the Axis of Surveillance with the difference:

Why you should fall to your knees and worship a librarian

Ok, sure. We’ve all got our little preconceived notions about who librarians are and what they do.

Many people think of librarians as diminutive civil servants, scuttling about “Sssh-ing” people and stamping things. Well, think again buster.

Librarians have degrees. They go to graduate school for Information Science and become masters of data systems and human/computer interaction. Librarians can catalog anything from an onion to a dog’s ear. They could catalog you.

Librarians wield unfathomable power. With a flip of the wrist they can hide your dissertation behind piles of old Field and Stream magazines. They can find data for your term paper that you never knew existed. They may even point you toward new and appropriate subject headings.

People become librarians because they know too much. Their knowledge extends beyond mere categories. They cannot be confined to disciplines. Librarians are all-knowing and all-seeing. They bring order to chaos. They bring wisdom and culture to the masses. They preserve every aspect of human knowledge. Librarians rule. And they will kick the crap out of anyone who says otherwise.

Everybody has a favorite line but mine is:

People become librarians because they know too much.

There is a corollary which Erica doesn’t mention:

People resort to data vacuuming because they know too little. A condition that data vacuuming cannot fix.

Think of it as being dumb and getting dumber.

There are solutions to that problem but since the intelligence community isn’t paying me, it isn’t worth writing them down.

PS: Go to the Library Avengers store for products by Erica.

Powered by WordPress