Many vendors seeking to sell hardware or software to the U.S. Government, particularly to defense and intelligence agencies, will find that cyber security product certification is mandated by federal procurement requirements (CNSSP 11) for these environments. We know, because many of our clients come to us for this very reason – fast, efficient, low risk evaluations that ultimately end up on the National Information Assurance Partnership (NIAP) Product Compliant List (PCL).
Our President Jason Lawlor talks with the Ottawa Business Journal to explain what Lightship Security is all about. Interview topics include:
As part of our continued product development efforts supporting assurance modernization, the Lightship team sometimes develop useful experimental tools or proofs of concepts. A while ago we developed a proof of concept to extract raw unconditioned entropy from a live running Linux system using the SystemTap API to produce loadable kernel modules. This was done as an exercise to explore Linux entropy characteristics. The code has been sitting around relatively unused, so we’ve decided to open it up under the GPL. It has been cleaned up a bit with additional informative comments, but this is proof-of-concept code with no warrant of fitness. You can find it on our GitHub account.
Read More
It’s hard to believe that it’s been two years since the launch of Lightship Security. Looking back to our founding, we collectively felt strongly that our vision and mandate would have to be centered on innovation and improvement of assurance outcomes within our industry. We did not want to simply start Lightship and keep doing “more of the same” that we had repeatedly seen in our 10+ years in the product certification industry.
We’re pleased to report that we have stayed true to the mandate. We have leveraged our agility, autonomy and some would say stubborn commitment to build a company and suite of technologies that can truly deliver “certification at the speed of development”. We have been able to accomplish this through key investments into our strategy:
Read More
It had been almost two years since NIST SP800-90B, draft 2 was released. When the final special publication was released on January 10, 2018, we hadn’t expect it to change as dramatically as between draft 1 to draft 2. After a cursory review, it would appear there are only minor changes to the quantitative elements. With the new published status, we will expect many Common Criteria schemes — if they don’t already — to soon mandate quantitative analysis of the raw entropy source.
While SP 800-90B was in draft form, North American schemes (NIAP and CSE) have permitted labs to evaluate a quantitative analysis (if available) or a qualitative analysis of a vendor’s entropy source. Qualitative analysis is usually relied upon when raw entropy is not easily obtained (such as from hardware sources or from closed-source systems), but is often onerous to author and often inefficient to get through evaluation. By contrast, quantitative analysis can bypass significant discussions on the merits of otherwise opaque hardware and software constructs and quantify the raw entropy as a single number. In this technical post, we will discuss one structured approach to quantitative analysis of a raw entropy source.
In Common Criteria, there has been increasing emphasis on the evaluation of the entropy used by manufacturers in the development and deployment of their systems. The following post discusses considerations and approaches for entropy health testing.
Health testing is, of course, necessary to ensure the proper functioning of the noise being provided to the critical components of the cryptographic systems. Therefore, if a vendor is investing resources in ensuring a strongly seeded DRBG, there should be some effort expended on doing some form of health testing.
In an agile development model, software is developed in incremental, rapid cycles with the goal of continuous improvement, fast flaw remediation and improved customer experience. Agile models advocate adaptive planning, evolutionary development, early delivery, fast iterations, and rapid response to change.
Can modern product assurance programs be designed to keep pace with agile development? At Lightship Security, we think so. In fact, we’ve made it our mission: Certification at the speed of development. We believe that a shift to “agile assurance” is a necessary step towards restoring trust and credibility to the cyber supply chain.
In this post, we are concerned with options to improve assurance outcomes provided by internationally adopted product certification programs. As a company, our focus is on developing solutions that support a modernized approach to product certification. This includes moving our industry towards agile assurance using contextual automation and supporting methodologies – we want to disrupt product certification as we know it.
In this post, we identify some common problem areas for vendors complying with the Network Device Collaborative Protection Profile (NDcPP). We’ll discuss how Lightship has adjusted to the new reality that every product going against the very prescriptive NDcPP will have gaps because of the strict level of conformance required – even if the same product was tested against a previous version of NDPP / NDcPP.
[Nov 6, 2017 update: NIAP has withdrawn Labgram #106 (moved to Superseded List) as NIST has announced an update to its transition plans. The NIST announcement indicates that a draft update to the relevant standard is expected in the summer of 2018. We recommend that vendors not rely solely on TLS_RSA ciphers, allow admins to disable TLS_RSA and add support for cipher suites that use DHE or ECDHE for key transport.]
[Sep 29, 2017 update: We have heard through unofficial channels that Labgram #106 is on hold and the that further guidance from NIAP should be forthcoming ‘soon’. It would be prudent to be prepared to provide guidance to admins to disable TLS_RSA ciphers and add DHE or ECDHE ciphers to your Security Target if not already present]
NIAP has issued Labgram #106/Valgram #126 – Impact of NIST 2017 Transitions to NIAP and it’s a doozy! You know that TLS_RSA_WITH_AES_128_CBC_SHA cipher suite that most NIAP Protection Profiles (PP) say is mandatory (even now)? Come January 1, 2018… not allowed. BOOM. Just like that. In fact, no TLS_RSA suites will be allowed in any NIAP PCL product. If TLS_RSA_* are the only cipher suites in use then the product will be archived off the list. Just like that.
The Communications Security Establishment (CSE) of Canada recently accepted Lightship Security as a Candidate Common Criteria Lab – an important milestones in the approval process to become an accredited IT security test lab. Accreditation is performed by the Standards Council of Canada (SCC) in partnership with CSE in accordance with ISO/IEC 17025 and allows participation in the twenty-eight nation Common Criteria Recognition Arrangement (CCRA).
“We are looking to disrupt the certifications landscape with our conformance automation software. Adding the Common Criteria lab allows us to drink our own champagne and perform quality certifications faster than ever before. We’re using Greenlight internally to support the accreditation process.” said Jason Lawlor, President of Lightship Security.
Greenlight is the Lightship Security designed and built software platform that automates testing against the latest Common Criteria Protection Profiles. All labs in Canada, regardless of experience are required to demonstrate ongoing technical competence to SCC and CSE reviewers. Lightship will be the first lab to integrate comprehensive automation through the use of Greenlight for real world evaluations.
