Zetter, Chaos Ensues →
Kim Zetter, writing at Wired's Security blog, illustrates a key problem in the Information Security Research Realm. Read Kim's reportage over at Wired to learn more...
Organized by the National Telecommunications and Information Administration (NTIA), a division of the US Commerce Department, the six-hour meeting marked one of the government’s first forays into the controversial world of bug reporting. But not all of the participants entirely welcomed the government’s involvement—some of them pointed out that a government that withholds information about zero-day vulnerabilities from software vendors in order to exploit them in the systems of adversaries is not exactly in a position to tell researchers and vendors how to handle the vulnerability disclosure process. - via Kim Zetter, writing at Wired's Security blog
Google Disables SSL and RC4, Better Late Than Never →
Adam Langley posts good news... Google Inc. (NasdaqGS: GOOG) has finally made the move, and is in the process of disabling SSL v3 (obsoleted 16 years ago) and RC4.
SSLv3 has been obsolete for over 16 years and is so full of known problems that the IETF has decided that it must no longer be used. RC4 is a 28 year old cipher that has done remarkably well, but is now the subject of multiple attacks at security conferences. The IETF has decided that RC4 also warrants a statement that it too must no longer be used. - via Adam Langley writing at the Google Online Security blog.
Friday Classic: Honans' Password →
A Friday Classic just for you, this time, plucked with demonstrable glee from the ad-ridden pages of Wired (to be fair, I am a print and digital subscriber as well...), and written by Matt Honan. In which, the eponymous Mr. Honan reveals his troubled relationship with passwords (and those that wish to abscond with same). Today's Must Read Classic post from November of 2012.
Theory of Incompleteness →
Fascinating post by Derek Brink writing at the RSA blog, discussing Gödel's Incompleteness Theorems, or Why Every Organization Needs an Incident Response Capability, Today's Must Read.
Cybersecurity Hall of Fame - 2015
The National Cyber Security Hall of Fame revealed the class of inductees last week, Fittingly, the old guard - as it were - is well represented. Interestingly, no equivalent announcement (or banquet) has been announced for the Class of 2015's counterparts in opposition, so to speak.
Securosis' Lane, Building Security Into DevOps
Adrian Lane, writing at Securosis (Adrian is also an Analyst & CTO, of the company)has published a timely piece targeting the deep inclusion of security into DevOps. Today's Must Read, and one of many from the folks at Securosis, a snip appears below. Ladies and Gentlemen, Girls and Boys, without further ado, Mr. Lane writes (sorry, one more ado... Note the last bulleted point in Mr. Lanes' snippet below):
Reduced errors: Automation reduces errors that are common when performing basic – and repetitive – tasks. And more to the point, automation is intended to stop ad-hoc changes to systems; these commonly go un-recorded, meaning the same problem is forgotten over time, and needs to be fixed repeatedly. By including configuration and code updates within the automation process, settings and distributions are applied consistently - every time. If there is a incorrect setting, the problem is addressed in the automation scripts and then pushed into production, not by altering systems ad-hoc.
Speed and efficiency: Here at Securosis we talk a lot about ‘reacting faster and better’, and ‘doing more with less’. DevOps, like Agile, is geared towards doing less, doing it better, and doing it faster. Releases are intended to occur on a more regular basis, with a smaller set of code changes. Less work means better focus, and more clarity of purpose with each release. Again, automation helps people get their jobs done with less hands-on work. But it also helps speed things up: Software builds can occur at programatic speeds. If orchestration scripts can spin up build or test environments on demand, there is no waiting around for IT to provision systems as it’s part of the automated process. If an automated build fails, scripts can pull the new code and alert the development team to the issue. If automated functional or regression tests fail, the information is in QA or developers hands before they finish lunch. Essentially you fail faster, with subsequent turnaround to identify and address issues being quicker as well.
Bottlenecks: There are several bottlenecks in software development; developers waiting for specifications, select individuals who are overtasked, provisioning IT systems, testing and even process (i.e.: synchronous ones like waterfall) can cause delays. Both the way that DevOps tasks are scheduled, the reduction in work being performed at any one time, and in the way that expert knowledge is embedded within automation, once DevOps has established itself major bottlenecks common to most development teams are alleviated.
Cooperation and Communication: If you’ve ever managed software releases, then you’ve witnessed the ping-pong match that occurs between development and QA. Code and insults fly back and forth between these two groups, that is when they are not complaining about how long it is taking IT to get things patched and new servers available for testing and deployment. The impact of having operations and development or QA work shoulder to shoulder is hard to articulate, but focusing the teams on smaller set of problems they address in conjunction with one another, friction around priorities and communication start to evaporate. You may consider this a ‘fuzzy’ benefit, until you’ve seen it first hand, then you realize how many problems are addressed through clear communication and joint creative efforts.
Technical Debt: Most firms consider the job of development to produce new features for customers. Things that developers want – or need – to produce more stable code are not features. Every software development project I’ve ever participated in ended with a long list of things we needed to do to improve the work environment (i.e.: the ‘To Do’ list). This was separate and distinct from new features; new tools, integration, automation, updating core libraries, addressing code vulnerabilities or even bug fixes. As such, project managers ignored it, as it was not their priority, and developers fixed issues at their own peril. This list is the essence of technical debt, and it piles up fast. DevOps looks to reverse the priority set and target technical debt - or anything that slows down work or reduces quality - before adding new capabilities. The ‘fix-it-first’ approach produces higher quality, more reliable software.
Metrics and Measurement: Are you better or worse than you were last week? How do you know? The answer is metrics. DevOps is not just about automation, but also about continuous and iterative improvements. The collection of metrics is critical to knowing where to focus your attention. Captured data – from platforms and applications – forms the basis for measuring everything from tangible things like latency and resource utilization, to more abstract concepts like code quality and testing coverage. Metrics are key to know what is working and what could use improvement.
Security: Security testing, just like functional testing, regression testing, load testing or just about any other form of validation, can be embedded into the process. Security becomes not just the domain of security experts with specialized knowledge, but part and parcel to the development and delivery process. Security controls can be used to flag new features or gate releases within the same set of controls you would use to ensure custom code, application stack or server configurations are to specification. Security goes from being ‘Dr. No’ to just another set of tests to measure code quality. - via Adrian Lane writing At Securosis
Over time the last bulleted point on Security, is a concicise description of both functional and technical answers (and a sea change of inclusion in optimized DevOps environs) to the often observed-by-developers 'No, you cannot do that' perception of information security team members... Most certainly Todays' Must Read. Enjoy.
USMC Testing Google Robotic Working Canine →
Via Sean Gallagher, writing at Ars Technica, comes this outstanding screed targeting a new Google Inc. (NasdaqGS: GOOG) robotic working canine at the United States Marine Corps Combat Development Command situated at USMC Base Quantico. If you read anything today about military robotics, read Mr. Gallagher's piece. Absolutely Outstanding.
Mozilla To Release Track Protection →
via Martin Brinkmann at the extraordinary GHacks blog, comes word of Mozilla Foundations' Firefox anti-tracking components slated for release in Firefox Stable 42 on November 3rd, 2015. Outstanding!
Iron Tiger →
You should know Graham Cluley, specifically because of his outstanding information security reporting; as evidenced, if you will, by his latest screed targeting the so-called Iron Tiger targeted attacks. Noted as today's Must Read.
Encryption, The Trick →
Quite likely one of the best articles on the problematic world of quantum encryption, written by Natalie Wolchover (published in Quanta Magazine) managed to bubble up through the jetsam of our collective interwebs yesterday. Today's Must Read.
US National Counterintelligence and Security Center, 'Not Our Job'
Writing at The Gaurdian, Sam Thielman reports on statements made in response to questions asked. Read it and Weep.