Sunday, October 28, 2012

DHS S&T Awards Cybersecurity Research Contracts


There is an interesting article over on HSToday.US that looks at an overview of 34 R&D contracts ($40 million) recently awarded by the DHS S&T Directorate to look at a variety of areas of cybersecurity research. The 34 contracts have been awarded to 29 research organizations including national laboratories, universities and private organizations. The research will address issues in 14 technical topics.

Anthony Kimery’s article looks at the broad picture of this research but doesn’t address how this might impact the industrial control system (ICS) community. That isn’t unexpected since the document that forms the basis for the research proposals being funded, the Cyber Security Research and Development Broad Agency Announcement (BAA) BAA 11-02, doesn’t mention control systems in its 82 pages and only mentions Stuxnet once (in an inappropriate manner at that).

Research Areas


Having said that, it is safe to assume that at least some of the research will result in information that will be useful to the ICS security community. Since we don’t have access to the specific research proposals we have to look at the technical topics listed in the BAA that the folks at S&T wanted the research community to address. Those technical topics areas (TTAs) are:

• TTA #1: Software Assurance;

• TTA #2: Enterprise-Level Security Metrics;

• TTA #3: Usable Security;

• TTA #4: Insider Threat;

• TTA #5: Resilient Systems and Networks;

• TTA #6: Modeling of Internet Attacks;

• TTA #7: Network Mapping and Measurement;

• TTA #8: Incident Response Communities;

• TTA #9: Digital Provenance;

• TTA #10: Hardware-Enabled Trust;

• TTA #11: Moving Target Defense;

• TTA #12: Nature-Inspired Cyber Health; and

• TTA #13: Software Assurance MarketPlace

ICS Security Excluded


The definition of three of these TTAs (#2, #4 and #12) specifically limits the research to areas affecting information technology. It is conceivable that results may have applications for ICS security, but the specific targeting of IT systems makes it unlikely that results will be easily transferable to the industrial control system setting.

TTA #7 looks at too large a scale to be of immediate usefulness in protecting control systems as it looks at the geographic and topological mapping of Internet hosts and routers.

ICS Systems


TTA #5 doesn’t mention control systems specifically but the description of targeted systems seems directly applicable to ICS; it targets ‘time-critical’ systems. It defines these as “a system for which faster-than-human reaction [emphasis added] is required to avoid adverse mission consequences and/or system instability in the presence of attacks, failures, or accidents” (pg 46). Interestingly this TTA suggests that researchers look at both security and resilience. Recognizing that malware is part of the cyber-environment the folks at S&T suggest that operation in the presence of malware is a key to security and resilience. They propose that researchers look at technology that enables (pg 47):

• Tolerating malware (for example, safely doing a trusted transaction from a potentially untrusted system);

• Investigating "safe sandbox" techniques for critical transactions; and

• Tolerating a residual level of ongoing compromise within components and subsystems of a larger system.

TTA #6 concerns the modeling of Internet attacks and this is where the folks at S&T mentioned Stuxnet (pg 49):

“Malware and botnet activity in recent months and years has intensified across the Internet and other critical infrastructures, with recent events, such as Conficker and Stuxnet, demonstrating the clear and present threat posed that is intelligent, adaptive, and effective at scale over increasingly shorter time periods.”

While Stuxnet certainly targeted control systems and did spread via the internet to non-target systems, the Internet was not used in spreading the malware to the targeted computers in Iran. Beyond this apparent misunderstanding, however, this TTA is at least partially addressed to research on control system security. The BAA makes this clear when it requires that:

“Technologies developed under this topic must perform their functions within legal and ethical boundaries. It is expected that the resultant tools would be commercialized and made available to critical infrastructure providers [emphasis added] in addition to government network operations.”

Limited ICS Applicability


The definitions of the remaining TTAs all could have some applicability to ICS security, but they are still basically addressing IT security issues. Depending on how the research proposals are structured will determine how much use they will be to the ICS community. Having said that, there are some parts of the TTAs that appear to be the most interesting from the view point of control system security.

TTA #1 looks at software assurance and calls for the development of new tools that will allow for the analysis of existing software, “discovering vulnerabilities, defects, and other types of weaknesses” (pg 36) as well as tools for runtime monitoring of software. The first will help identify potential security holes and second will help to identify attacks in progress. Both will be of great help in protecting any cyber-system from attack.

TTA #3 is very broadly defined, maybe too broadly defined to be of practical use but it does raise the issue of the inherent conflict between security procedures and ease of use. It note that (pg 42):

“Security must be usable by non-technical users, experts, and system administrators. Put another way, systems must be usable while maintaining security. In the absence of usable security, there is ultimately no effective security. The need for usable security is increasingly being recognized, as is the fact that usable security is a challenging problem.”

TTA #8 introduces a new term in cybersecurity response; the CSIRT – the Cyber Security Incident Response Team. This is a sociological research requirement designed to determine “the characteristics that make an excellent CSIR individual, team, and community, and how these capabilities are identified and enhanced” (pg 54). While this might be helpful in the long run it isn’t going to make any immediate change in the funding and manning of such organizations.

TTA #9 is a socio-economic look at cyber-attacks. It is a one-dimensional analysis of the problem of cybersecurity that asks researchers to look at the economic motivation of attackers. It completely ignores the political aspects of attackers; there is no acknowledgement of the problem of cyber-terrorism or nation-state directed attacks.

TTA #10 asks researchers to look at the importance of digital provenance; “the chain of successive custody, including sources and operations, of computer-related resources such as hardware, software, documents, databases, data, and other entities” (pg 61). Digital provenance is going to be increasingly important as more and more counterfeit components and software make their way into the control system supply chain.

TTA #11 addresses the concept of hardware security as opposed to ensuring security through software and firm ware. S&T asks researchers to look at “new technologies will ensure that hardware will not inadvertently leak secrets or execute malware (even if penetrated by malware), and it will execute security-critical tasks even if partially compromised” (pg 64). It certainly sounds like a worthwhile goal, but it would seem to limit some of the current functionality found in systems where firmware or software allows for expansion of capabilities.

TTA #13 introduces a novel idea, building into cyber-systems something akin to the biological response to infections. The BBA notes:

“In the future, network components must have heightened ability to observe and record what is happening to and around them. With this new awareness of the system health and safety, these “self-aware systems” enjoy a range of options: these system may take preventative measures, rejecting requests which do not fit the profile of what is good, a priori, for the network; these systems can build immunological responses to the malicious agents which they sense in real time; these systems may refine the evidence they capture for the pathologist, as a diagnosis of last resort, or to support the development of new prevention methods. In the future, system owners should be able to monitor and control such dynamic cyber environments.”

TTA #14 ties back into TTA#1. It asks for the establishment of (pg 75): “a software assurance facility and the associated services that will be made available to both software analysis researchers and software developers, both open source and proprietary. Software analysis researchers will have access to services allowing them to test new algorithms for static, dynamic, and binary analysis against a variety of software in a multi-platform environment.” The value of such a facility is obvious, but it requires the successful implementation of TTA #1 to provide the tools of the facility.

Results Are What Counts


The awarding of these contracts is an important step, but the amount involved is a relatively small investment in cybersecurity. And it must be remembered that the investment in research does not always (or even often) produce the desired results. Still it is an important step being taken by DHS and some of these programs should start paying off in the next year or so.

Saturday, October 27, 2012

CFATS Knowledge Center Update 10-26-12


Yesterday the folks at the CFATS Help Desk updated the CFATS Knowledge Center by eliminating one frequently asked question (FAQ # 1649) and essentially replacing it with a new Article, # 1729. While both deal with the process for a facility to request an extension of a CFATS submission deadline, the new procedure is substantially different from the previous process and there is a much more detailed explanation of the procedure in the new Article.

Written Requests


The old FAQ was essentially a provision of the mailing address (one for USPS and one for delivery services) for the Director of ISCD. The only other information provided was a brief statement about what had to be included in the request (“please include the facility ID and an explanation for the facility’s extension request”) and a reminder to properly mark and mail any Chemical-Terrorism Vulnerability Information (CVI); short, sweet and to the point.

The procedure for sending a written request for an extension remains much the same. They did eliminate the double printing of the address, providing just the one address for both modes of snail mail delivery. If you are using USPS you can still eliminate the two lines between “Mail Stop #0610” and “Washington, DC 20528” as mail to government offices gets checked and deloused as necessary at the ‘Mail Stop’ before it gets to the District.

Electronic Requests


There were no provisions mentioned in the old FAQ for the electronic submission of extension requests. The closest it came was a specific prohibition against faxing such requests to the Help Desk.

The new CFATS Knowledge Center Article explains how a new application within the on-line Chemical Security Assessment Tool (CSAT) allows a Submitter to submit an extension request on-line. Once signed into CSAT and on the CSAT Survey List screen there is now a button for “Request Extension” for the pending survey (SVA or SSP). The Article goes on to explain the steps that need to be followed to complete the request, but they do seem to be fairly straightforward and in keeping with the feel of the rest of the CSAT tools.

Once the request has been submitted the “Request Extension” button on the CSAT Survey List screen will be replaced by an “Extension Request Pending” message. If you submit your request by snail mail, this same change will let you know that ISCD has started the process of reviewing your request.

Notifications


There is one other small change that has been made in this process that you have to be fairly alert to catch. At the end of the first paragraph in the Article there is the following sentence:

“Upon receipt of the extension request, whether in paper or electronic form, the Department will review all relevant information and notify the facility of the Department’s decision through CSAT [emphasis added].”

Recently ISCD stopped sending their CSAT related letters to the facility via FedEx (Did the Post Office know about a government agency using FedEx instead of USPS?) . They now only provide an email notification to the Submitter that a copy of the letter is available on CSAT. I’m not sure if this was done as a cost saving measure (and it surely is) or a security measure as FedEx doesn’t ensure ‘eyes only’ delivery directly to the addressee. Since CSAT is a ‘secure on-line tool’ this does increase security.

Phishing Problem


Or does it? The folks at ISCD have inadvertently compromised the security of the CSAT tool by setting up people registered on CSAT for phishing attacks. Let me explain….

ISCD requires that passwords for the CSAT tool be changed every 90 days; a bit excessive perhaps, but it does increase security particularly because there can be long periods between sign-ons. To help people remember to update their passwords, ISCD sends out a “Password Expiration Notice” email at 60-days; intended as a helpful reminder. Unfortunately, they include a link to the CSAT site in that email making it easier for an individual to complete the update process.

Anyone with any cybersecurity sense knows that clicking on a link in a ‘password update’ email is a sure way to be taken to a fake web site that will accept your sign-on name and your current and new password; giving someone else full access to your site information. Unfortunately, the number of people with cybersecurity sense appears to be limited as this is one of the most successful phishing ploys around.

Now this isn’t a new problem at ISCD. I wrote about this back in 2008. It has recently come to my attention that this problem is continuing to this day. If they must send out reminder emails, ISCD needs to conduct a significant educational campaign reminding people about the problem of clicking on links in emails that to go to “sign-on pages”. They MUST also stop including such links in their emails; all emails going to registered users of CSAT.

Friday, October 26, 2012

ICS-CERT Updates CoDeSys Alert


Okay, I have to apologize to the folks at DHS ICS-CERT for casting aspersions upon the integrity of their Alert/Advisory product. This morning ICS-CERT published an update on the CoDeSys alert originally issued in April of this year concerning vulnerabilities that Reid Wightman had identified during Project Base Camp in the CoDeSys SCADA application. This update addresses the new exploit tools that Reid reported about over on the blog at DigitalBond.com.

The folks at ICS-CERT then went me one better; they posted a link (provided by CoDeSys) to a page that identifies the vendors (and the device names) that are using the CoDeSys application that is at the heart of the problem. It’s a little more complex than just a list of names, you have to fill in some search blocks and hit the “Show” button, but it is a very interesting little list of vendors.

NSTAC Teleconference Announced – 11-05-12


Today DHS published an announcement in the Federal Register (77 FR 65393) for a teleconference of the President’s National Security Telecommunications Advisory Committee (NSTAC) on November 5th, 2012. The NSTAC advises the President on matters related to national security and emergency preparedness (NS/EP) telecommunications policy. This teleconference is a public meeting.

The Agenda


There are three items on the current agenda; two subcommittee updates (no action expected) and the approval of a letter report to the President. The subcommittee reports address;

• The Nationwide Public Safety Broadband Network Subcommittee is examining the national security/emergency preparedness implications of the NPSBN and how to allow priority access during national security events; and

• The Secure Government Communications Scoping Subcommittee is looking at the use of commercial-off-the-shelf technologies (COTS) to secure unclassified government agency communications.

During the period of June to September of this year the NSTAC conducted a review of the operations of the DHS National Cybersecurity and Communications Integration Center (NCCIC). According to the notice the purpose of the study was to determine whether the NCCIC has developed in ways consistent with previous NSTAC recommendations. A letter report has been prepared for review and approval.

Another Late Announcement


This is the third announcement of a DHS NPPD sponsored meeting that was not published within the 15 day time limit required by government regulations; this was published 10 days before the meeting so it does provide more advanced notice the previous two. And the reason does appear to be more legitimate:

“A notice of the meeting of the NSTAC is being published in the Federal Register with less than 15 days notice due to an effort to assure the accuracy and validity of the NSTAC meeting agenda and contents. NSTAC changes in leadership and stakeholder approval of the NSTAC meeting discussion points created a longer than usual adjudication process.”

If it weren’t for the two previous very short term notifications (three days in one case) by NPPD, this probably would not be worth mentioning. And this is a teleconference so no one has to make travel and lodging arrangements to attend this meeting. Having said that, the final sentence of this notice bothers me:

“Although the meeting notice was published in the Federal Register late, the agenda will be published on the NCS Web site: www.ncs.gov [presumably by the October 30th date mentioned in the notice - PJC] and an email will be sent out to the NSTAC Members.”

This ignores one of the main purposes of requiring a 15 day notice be published in the Federal Register. That is to inform the public so that they may participate/observe the deliberations of this private body that provides information and insights to the President. Again, not such a big deal since this is a teleconference, but the attitude bothers me.

Public Participation


The public can listen in on these deliberations (register with Ms Gallop-Anderson via email -  deirdre.gallop-anderson@hq.dhs.gov) by 5:00 pm EST on October 29th, 2012. There will be a public comment period at the end of the meeting and registration is also required for that. Documents associated with this meeting will be posted on the NSTAC web site by October 30th. Written comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2012-0063) and must be received by November 19th, 2012; way too late for consideration during the teleconference.

ICS-CERT Updates Generic ICS Alert


Yesterday the DHS ICS-CERT updated a generic control system alert that they originally released last February. This update provides a new piece of threat information and a suggestion for using that information to strengthen industrial control systems.

Shodan Information


The alert notes that some unnamed researchers had approached ICS-CERT with information on “a list of more than 500,000 control systems-related devices using supervisory control and data acquisition (SCADA) and other ICS-related search terms” (page 1). Since SHODAN only finds systems that provide at least a minimal face to the Internet, this means that there are at least 500,000 internet-facing control system devices; so much for having control systems isolated from the internet.

The alert goes on to explain that ICS-CERT is trying to “to notify the owners of the identified IP addresses” but it doesn’t take much imagination to figure out that this might take some time. And then there are the addresses that they has no intention of notifying (Iwould guess that devices in Syrian chemical weapons manufacturing sites or Iranian uranium enrichment plants probably would not get the call for example).

In the meantime the second addition in the update is the recommendation that owners use SHODAN as a tool to determine if any of their equipment shows up in the search. This would help them determine which parts of their system need immediate attention. This is not a new idea, I suggested this almost a year ago.

The Real Reason for the Update?


Now I don’t want to be accused of looking for devious alternative reasons for ICS-CERT doing things, but the SHODAN information in this alert isn’t really new. Okay, the ‘500,000’ number is higher than I’ve seen before, but ICS-CERT did an alert specifically on the SHODAN threat in December of last year. Other than the number of detected systems there is nothing in this update that wasn’t better explained in the other alert. Maybe they should have updated that SHODAN alert not this one.

Sharp eyed readers will note that the original issuance of this alert came just after Dale Peterson’s Project Basecamp produced some exploits for number of serious ICS vulnerabilities in PLCs and their communications links. It seems odd that today was the day that Reid Wightman posted a blog on Dale’s DigitalBond [Corrected improper link; 10-26-12 4:21 pm EST] site concerning the latest tools to be used to exploit the last of the Basecamp vulnerabilities.

Interestingly, the CoDeSys vulnerabilities that these tools address are actually a bigger problem in many ways than the problems Dale’s folks identified in the other systems. The reason is that, according to Reid, over 260 vendors use the affected CoDeSys software in their systems. I haven’t seen a list of the affected vendors, but I think that we can safely assume that some significant number of them have never told their customers about the CoDeSys components in their systems. Who knows how many will ever tell their customers about these vulnerabilities. I am sure that ICS-CERT is not going to produce an alert/advisory for each of those affected systems.

Now there is already an alert on the CoDeSys vulnerabilities reported at Project Basecamp. Normally I would expect to see an update on that alert this afternoon, but ICS-CERT has been treating vulnerabilities identified by Reid a bit strange of late. If we don’t see an update later today, then I’m really going to suspect that this update is an attempt to cover the appropriate bases without giving Reid any credit.

Wednesday, October 24, 2012

A Real White Powder Attack?


Since the end of the anthrax attacks in 2001 we have seen a huge number of bogus WMD attacks on various public and private institutions by people sending a ‘white powder’ in an envelope to someone, frequently with various warnings about the pretend danger associated with the powder. It has become a great show in the media to make subtle fun of the over reaction of the security and hazmat folks to the danger that turns out to be powdered sugar or flour or something equally innocuous. According to news reports out of Sweden we have a confirmed report of a ‘highly toxic and corrosive’ white powder being delivered in an envelope to the US Embassy in Stockholm last week. There were no reports of any injuries associated with this apparent attack.
Sweden’s Security Service (Säpo) is now investigating the incident and has not released the identification of the material, so we really don’t know how serious the problem really was. It does appear that it was serious enough to make the hazmat response to similar letters seem much more reasonable. That’s the problem with terror attacks (assuming that this was one and not just a person with a personal grudge with a person at the Embassy); a near miss attack will be successful in changing the official behavior of people not directly affected.
Assuming that this was a chemical, as opposed to a biological, attack it just goes to show that it doesn’t take a Screening Threshold Quantity (STQ) of a DHS Chemical of Interest (COI) to execute a chemical attack. I’m not saying that CFATS needs extension (were having enough problems implementing this at a limited number of truly high-risk facilities), but people at all chemical facilities have to have some sense of security awareness.

Cybersecurity Reorganization at DHS


FederalNewsRadio.com is reporting that the National Protection and Programs Directorate (NPPD) of DHS is reorganizing the Office of Cybersecurity and Communications. There are not a lot of details yet available, but Jason Miller is reporting that:

“The National Cybersecurity and Communications Integration Center (NCIC), led by Larry Zelvin, will bring together the assorted operational offices, including the U.S. Computer Emergency Readiness Team (U.S. CERT), the Control Systems Security Program [emphasis added], the National Coordinating Center and national level exercises — all under one division.”

What this will mean for budgeting, personnel and operations remains to be seen.

Tuesday, October 23, 2012

ICS-CERT Publishes 2nd Wightman Advisory


A month ago ICS-CERT published an advisory for a hard-coded root credential vulnerability in the ORing DIN-Rail Device Server that was reported in an uncoordinated disclosure by Reid Wightman, then working with DigitalBond. Reid’s blog post about that vulnerability reported that the same vulnerability existed in Korenix Jetport 5600. In fact, he noted that the backdoors were identical and “the firmwares are eerily similar”. Today, ICS-CERT published the advisory for the Jetport 5600.

Unlike the earlier advisory where ICS-CERT threw the vendor under the bus for failure to correct the deficiency, ICS-CERT reports that Korenix has developed an upgraded version of the firmware that removes the root and guest accounts as well as the current version of OpenSSL. The advisory doesn’t note, however, that anyone has confirmed that this corrects the problem.

If Reid is right about the two devices sharing the same firmware, then this update should also correct the problem in the ORing server. I wonder if anyone has checked this out?

Where’s the Alerts?


Okay, I tried to avoid it, but I just have to ask. Why wasn’t there an alert published back in June when Reid published his blog post about the vulnerability (complete with exploit code) about both of these systems? Wouldn’t the owners of these devices (most of which had probably never heard of DigitalBond) want to know that they were vulnerable to having their system completely taken over by anyone with an interest in messing with them?

Monday, October 22, 2012

Reader Comments – Tofino Technical Discussion


We have had quite a discussion started about my post last week about a new technique being offered by Tofino Security to help secure communications within a SCADA/ICS system. Apparently I didn’t get my description of their product/service too far from correct, but there has still been a lot of discussion back and forth about what it can do and what it can’t do. To be fair, Eric Byres doesn’t claim that this is the be-all-end-all security device, but that it does provide another level of security in a properly designed defense-in-depth security plan.

Readers of this blog that truly understand the ins and outs of ICS security, please read all four posts; two by an Anonymous reader, one by Joel “the SCADAHacker” Langill, and one by Eric. There is lots of good information about how this system works and how it can be integrated into an effective ICS security system. And by all means, feel free to join in the discussion; I love learning new things about ICS security.

If you are a reader that thinks that you have a pretty good understanding of the ins and outs of ICS security, take a read through the comments. If you get lost in some of the terminology in the first couple of sentences, but understand the general gist of what they are saying (kind of like me, in other words) stay on the outskirts of any serious SCADA security conversation and nod your head from time to time and you’ll look pretty smart (works for me). But please, get some professional help in designing, implementing and maintaining your ICS security system.

If the discussion is in archaic Greek as far as you are concerned, then run, don’t walk, to the nearest introductory course on ICS security before you even talk to an ICS security contractor. Otherwise, you are likely to pay too much for hardly any security.

In any case, read the discussion, it is very educational.

Sunday, October 21, 2012

PHMSA NPRM to Convert SPs to Regulation


Monday’s Federal Register (available on line yesterday) contains a notice of proposed rulemaking (77 FR 64450-64461) from the Pipeline and Hazardous Material Safety Administration. The NPRM proposes to amend the Hazardous Materials Regulations (HMR) to incorporate provisions contained in certain widely used or longstanding special permits (SP) and certain competent authority (CA) approvals that have established safety records.

SPs and CAs to Incorporate


The NPRM would incorporate the following special permits into the HMR:

DOT-SP 9275 authorized the transportation in commerce of certain limited quantities of liquids and solids containing ethyl alcohol and exempts these shipments from the provisions of HMR.

DOT-SP 11263 authorizes the transportation of solid coal tar pitch compounds, Class 9, in open-top and closed-top sift-proof metal cans or fiber drums.

DOT-SP 11836 authorizes the transportation of specific ammonia solutions in specification UN1H1drums, UN3H1 jerricans, and UN6HA1 composite packagings that do not meet the provisions in Sec. Sec.  173.24 and 173.24a.

DOT-SP 12134 authorizes the transportation of spent bleaching earth as a Division 4.2, solid, PG III, exempt from the provisions of the HMR, except as specifically required by the special permit.

DOT-SP 12825 authorizes the transportation of life-saving appliances, self-inflating, that contain non-DOT specification steel cylinders for the purpose of movement between a vessel and a U.S. Coast Guard approved inflatable life raft servicing facility in conjunction with the servicing of such life-saving appliances.

DOT-SP 14479 authorizes the continued use of regulated medical waste containers manufactured before October 1, 2006 and marked with an alternative shipping name for UN 3291 and orientation arrows that deviate from prescribed specifications.

The following Competent Authority Authorizations would also be incorporated into the HMR by this NPRM:

CA2006060005 authorizes the manufacture, mark, and sale of UN5M1 and UN5M2 multi-wall paper bags with individual paper wall basis weights that vary by not more than plus or minus 5% from the nominal basis weights reported in the initial design qualification test report.

CA2006060006 authorizes the manufacture, mark, and sale of UN4G combination packagings with outer fiberboard components that have individual containerboard basis weights that vary by not more than plus or minus 5% from the nominal basis weight reported in the initial design

CA2006010012 authorizes the manufacture, mark, and sale of UN4G combination packagings with outer fiberboard boxes and with inner fiberboard components that have individual containerboard basis weight that vary by not more than plus or minus 5% from the nominal basis weight reported in the initial design qualification test report.

FAA Modernization and Reform Act of 2012


Section 824 of the FAA Modernization and Reform Act of 2012 (Public Law 112–95 126 Stat 130) provided specific exemptions from portions of the HMR for the transportation of certain oxidizing gasses in cylinders aboard aircraft in Alaska to communities with limited transportation access. This NPRM would add §175.34 to 49 CFR to implement this legislative exemption. In practice this eliminates the need for the following current Special Permits: 14903, 14908, 15062, 15075, 15076, 15077, 15078, 15079, 15092, 15094, 15095, and 15143. It does not, however, directly address these SPs.

Special Permit ICR


The incorporation of these Special Permits and Competent Authority Authorizations will eliminate the need for the holders of these exemptions and authorizations from periodically having to renew these actions. As a result PHMSA notes that the information collection request (ICR) supporting the applications (OMB # 2137-0051) will have a net decrease in the number of respondents, responses, burden hours (decrease of 434 for each) and burden costs (a decrease of $17,143). PHMSA will submit a request for a revision to this ICR to OMB based upon these decreased.

Public Comments

PHMSA is soliciting public comments on both the NPRM and the ICR revision. Comments on both can be submitted via the Federal eRulemaking Portal {www.Regulations.gov; Docket #PHMSA-2011-0158 (HM-233C)}. Written comments should be submitted by December 21st, 2012.

PHMSA Publishes Gas Cylinder Safety Advisory Notice


The Pipeline and Hazardous Material Safety Administration has published a safety advisory notice (77 FR 64590-64591) in Monday’s Federal Register (available on line yesterday) concerning an unknown number of high-pressure gas cylinders that were improperly marked and certified by George Welding and Supply Company of Montoursville, PA between 2001 and 2012.

The Safety Advisory notes that George Welding and Supply Company is not “approved to requalify DOT-specification cylinders or mark such cylinders as being requalified”. Apparently George Welding and Supply marked some number of cylinders with the Requalifier Identification Number (RIN) of the following approved companies:

C171--Proshield Fire Protection, Waterloo, IA;

C004--Swartz Fire & Safety Equipment Co., Inc., Bellefonte, PA;

C411--Advanced Fire Protection Services, Inc., Ft. Walton Beach, FL;

C951--Peifer's Fire Protection, Inc., Pillow, PA;

D477--NASCO, Colorado Springs, CO;

D575--Sea Sports, Inc., Hyannis, MA;

D576--Chenango Welding Supply, LLC;

A101--Airgas North Central, Waterloo, IA; and

D322--Allstate Fire Equipment Co.

The notice states that cylinders actually requalified by the above company are not covered by this notice; only cylinders serviced by George Welding and Supply Company are affected. People that have cylinders with the above listed RINs should check with their supplier to see who was responsible for their most recent requalification.

For cylinders reported requalified by George Welding and Supply Company, the Safety Advisory notes that they may not be safe and recommends the following actions be taken:

• Cylinders that are filled with an atmospheric gas should be vented or otherwise safely discharged; or

• Cylinders that are filled with a material other than an atmospheric gas should not be vented but instead should be safely discharged; and

• Prior to refilling, the cylinders must be taken to a DOT-authorized cylinder requalifier to ensure their suitability for continued service.

TSA Publishes HME ICR 60-Day Notice


The Monday Federal Register (available on line yesterday) includes a 60-day notice (77 FR 64533) from the Transportations Security Administration of their intent to submit to OMB a renewal of the information collection request supporting the Hazardous Material Endorsement (HME) credential program. Readers might remember that a short-term renewal of the HME ICR had been granted in July of this year, but OMB requested updated burden information to provide a longer term renewal.

ICR Information


This ICR notice provides the updated information requested by OMB. The table below shows the new data and the data provided in the previously approved request. Both sets of data are provided on an annual basis

 
New Data
Previous Data
Applications
295,000
300,905
Burden (hours)
960,000
994,096
Burden (Million $)
$25.0
$27.4

While this ICR notice goes into great detail why there was a change in the information being collected (and this was covered in the previously approved request) there is no indication why TSA expects the number of HME applications to continue to decline. There are also some unexplained decreases in the expected number of hours/application (3.25 vs 3.30 hours per application; minor to be sure) and burden cost per hour ($26.04/hr vs $27.52/hr; this may be partially due to rounding of the burden cost in the notice).

Industry Impact


I’m not sure where TSA gets its information to calculate the annualized number of applicants. It could be something as simple as extrapolating from the current rate of new and renewal applications (probably the most likely as this would be all internal data) or the TSA could be using some sort of survey data provided by the trucking industry or some sort of consultant. In any case an almost 2% decline in the annual number of HME applicants bodes ill for the HAZMAT transportation industry.
 
Unless there is an off-setting increase in the rate of application approvals (and I have not seen any TSA data on their rate of application approvals) or decrease in the number of HME revocations (no data seen there either) this means that there will be a continually shrinking pool of drivers qualified to haul HAZMAT loads. This can only lead to increased shipping costs.

Thursday, October 18, 2012

Chem-Cybersecurity Plan


With this being National Cybersecurity Month every DHS entity on TWITTER® is tweeting tips for cybersecurity. Some are good and others not so, but they are mainly targeted at IT cybersecurity. Take for example this one from StopThinkConnect:

“A comprehensive #cybersecurity plan focuses on 3 key areas: prevention, resolution & restitution. More info: http://bit.ly/U6Hm3H #ChatSTC

A number of other people have tweeted in with their suggestions for additions and substitutions, but all of the ones that I have seen still seem to concentrate on information security. It would be nice if someone would come up with something targeted at the ICS community. Well how about me? Okay here goes my 3 key areas for chemical facility cybersecurity:

Prevent – Stop most attacks before they can happen. Ensure that all systems are adequately isolated from the internet and corporate enterprise network. Ensure that all appropriate patches and updates are properly vetted, checked and installed. Ensure that access to the ICS system is limited to those with a verifiable need and at the lowest possible authorization level commensurate with that need.

Detect – Unauthorized network intrusions are detected at the earliest possible instant with a combination of in-depth tools that are capable of detecting and documenting the progress of the intrusion.

Safe Shut Down – Standalone chemical cyber-safety systems are capable of putting the process/storage/movement of chemicals into an inherently safe mode in the event that any cyber or physical intrusion or incident puts the process into an unstable configuration.

Remember, you can’t possibly prevent all attacks. There will always be some new hole that someone can find that would allow a determined enough attacker to get through. Also you are not going to be able to detect every attack soon enough to prevent it from catastrophically affecting your system. The main goal has always got to be to have the tools in place to safely shut down the system in the event of any mishap, intentional or otherwise, cyber or physical. Good luck, we all need it.

A New Cybersecurity Technique


There was an interesting blog post by Eric Byres over at TofinoSecurity.com describing a new way to use their Tofino Industrial Security Solution to address the problem of updating multiple control system devices as new security vulnerabilities are discovered and corrected. Now I am not qualified to evaluate how well this actually works, but the basic concept sounds so good that I just have to talk about it. WARNING: Technical errors in this post are mine alone, don’t blame Eric.

The Problem


In an earlier blog post Eric wrote about a real scary problem with Microsoft updates/patches that pose a particular problem for control systems. But that isn’t the limit of the problems with patches. The most basic problem is that most organizations don’t want to interrupt their process to take their control system down to execute the appropriate patches, complete with the appropriate testing and validation required to ensure that there are now unintended interferences with their operations.

Next there is the problem with the apparently ever increasing number of patches that would have to be applied to the system. The increase in attention that is being directed at the vulnerabilities to be found in control systems has resulted in an ever larger number vulnerabilities being published. If you look at the large number and variety of smart devices connected to modern control systems it is easy to see that there could be any number of patches having to be made to the control system on a fairly routine basis.

The more patches that are required to be made to keep the system protected against attacks, the more likely it will be that the owner/operator will make the very reasonable decision not to do any patches. Rather than trying to guess which vulnerability might really pose a threat to their system, the practical decision is that there is no reasonable method of making that determination so why waste the time making the wrong patches.

The Solution


There is one very common thing associated with a large percentage of the vulnerabilities reported by ICS-CERT; their remote exploit involves a very specific type of communication being made to the vulnerable device. These can be default passwords, specially crafted messages, or commands to specific ports on the devices.

What Tofino has is the ability to program these vulnerability signatures into their device which monitors control system communications. When it detects one of the signature events it blocks that communications, logs the event, and sends out an alarm so that humans can intercede. As new vulnerabilities are identified the signature library can be upgraded without any direct effect on the control system.

Okay, things are a bit more complicated than that, but this isn’t a Tofino sales presentation, contact Eric or one of his sales people if you want a more complete explanation of how their system works.

Shortcomings


Now Eric doesn’t claim that this is a one-hundred percent answer to ICS security problems. Zero day vulnerabilities are obviously not covered; by definition there is no signature available for a 0-day. Spear phishing attacks that attempt to gain user credentials or insider attacks would not be directly affected by this system.

Tofino Security develops their signature list based on information provided by the vendors. Not all vendors are willing to work with them so not every device is covered. If you have one of these Tofino systems and one of your device vendors does not support it through Eric’s people you might want to ask pointed questions. Eric has mentioned that they have the capability to develop some signatures on their own based upon knowledge of known vulnerabilities, but I suspect that sort of service starts to get pricey.

This system monitors communications to and from the control system. If there is some sort of direct access to peripheral devices through physical connections, wireless access or whatever, this system cannot intercept/block that communications.

No one else has mentioned it, but one of my pet peeves doesn’t seem to be addressed by this system. If there are embedded systems, programs or subroutines from vendors that you are not aware of and those systems have vulnerabilities, it seems unlikely that signatures for those will be addressed by the system. You see, when this is installed you tell Tofino Security what systems you have and they program your device with the signatures for those systems. If you don’t tell them because you don’t know about the device, program, or subroutine, then they can’t help you.

Suggestions


The first suggestion is directed towards the vendors that aren’t currently working with Tofino; start. As this system is adopted by more owners the failure to be a supporting vendor is going to start to impact sales.

Second, it seems to me that for vendors that have been made aware of vulnerabilities, but have not yet had the chance to complete work on a distributable patch, this is a good way to provide some level of protection to your customers while you’re hard at work on the real fix. This would be especially true for those uncoordinated disclosures that put your customers at the most risk. Providing Eric’s team with vulnerability signatures as early in the process as possible would be an excellent selling point.

Finally, it seems to me that Tofino Security would benefit from having a team actively watching the uncoordinated disclosures being made and working with those researchers to develop signatures for those vulnerabilities. For vendors that they are working with, this would provide a valuable service. For their customers that have equipment from non-cooperative vendors it would provide them some level of protection while they wait out the replacement life-cycle of the equipment.

Wednesday, October 17, 2012

CG Meeting Update Posted


The Coast Guard today published in today’s Federal Register (77 FR 63849) the correction to their FSO Training meeting registration link that I described in my post last Friday. For more details about the meeting see my original post.

ICS-CERT Updates Shamoon JSAR


Yesterday DHS ICS-CERT, in conjunction with US-CERT, issued an update of the Joint Security Awareness Report on the Shamoon malware. While this information stealing tool is suspected as being responsible for shutting down the Saudi oil company IT network, there has been no mention of it being used, or being specifically capable of being used, against control systems.

New Information


The new information included in the Update (on page 2) are three new entries in the ‘Tactical Mitigations’ section of the JSAR. The first is a ‘no duh’ entry, the second is somewhat useful, and the third is somewhat confusing. In general these three additions hardly make issuing an update worthwhile, particularly for the ICS community.

Drill Your Recovery Plan


I did say that this was a ‘no duh’ mitigation strategy, but to be fair ‘drill your recovery plan’ is one of those common sense strategies that probably doesn’t get done much. I’m not sure that simply listing it in a JSAR will help that. Perhaps an explanation of why any plan must be practiced (drilled) to be effective will help.

The military probably has the best experience in developing, perfecting and executing contingency plans. They know from bitter and painful experience that plans inevitably have short comings due to assumptions made in the planning process. Most often these assumptions are not clearly understood and frequently not even identified.

Practicing a plan will usually point out some of the shortcomings in the plan that are a result of inaccurate or incomplete assumptions. This does require, however, that after the plan has been exercised, that a clear and complete analysis has to be made of the areas where the plan did or did not work. And then the plan has to be modified to correct the deficiencies and build on what was done right.
 
Finding these mistakes during an exercise is much less painful and makes them easier to correct than if they are discovered for the first time while responding to the real thing.

Tuesday, October 16, 2012

GE Proficy Advisory from ICS-CERT


Yesterday afternoon the DHS ICS-CERT published an advisory for multiple vulnerabilities in the GE Intelligent Platforms Proficy Real-Time Information Portal. The vulnerabilities were reported by Kuang-Chun Hung of Information and Communication Security Technology Center (ICST) in a coordinated disclosure and had previously been published on the US-CERT secure Portal library.

The Vulnerabilities


Three separate improper input validation vulnerabilities could allow a skilled attacker to remotely execute a denial of service (DoS) attack. GE has provided patches for three of the affected versions (3.0 SP1 SIM 44, 3.5 SIM 17, and 3.5 SP1 SIM 1). Owners of earlier versions are encouraged by GE to upgrade to newer, patched versions of the system.

Upgrading Industrial Control Systems


We are seeing an increasing number of notices about having to upgrade older versions of ICS products to get security fixes put into place. In many ways this is to be expected. A vendor has to make a business decision as to where they are going to expend valuable programming assets, fixing old products or producing new products. In IT systems, this is not nearly the problem that it is in ICS products since we have come to expect having to buy new systems on a frequent basis to deal with new versions of operating systems.

ICS owners, on the other hand, have invested money in their control systems that they expected to see remain in operation for a long time; an eternity in IT-system years. In addition, they have to consider the compatibility of the new control system version with a large number of existing peripheral devices. Even where compatibility may have been assured, modifications made on-site to control devices may render them incompatible with the new system.

Even when the new systems are ‘completely compatible’ with existing equipment, control-systems are not operating in a plug-and-play environment like we see in modern IT systems. Extensive tuning may be required before the control system operates effectively, and multiple iterations of that tuning may be required because of process interactions with other devices.

Making the decision to upgrade to a new version of a control system is not a decision to be made lightly. Vendors should also realize that many organizations, when forced to make such a decision, may decide that it makes for an opportune time to change vendors. I have been in an organization that made just such a decision; the time and effort that would have been required to upgrade was not that much different than that for going to a new system. The other vendor had capabilities that we had wanted to add to our system, but was not worth the hassle of a change on their own. We figured that since we were changing anyway we might as go all the way.

Monday, October 15, 2012

Video Surveillance at Chemical Facilities


I got an interesting email from John Honovich, the owner of IPVM.com a site focused on all things about video surveillance and one of the few independent commentators on that field. He wrote to tell me that they were preparing to do a blog post about video surveillance at chemical facilities and was interested to know if I had any specific blog posts about the subject that might be of interest to their readers. A quick search of this site showed that just about every post on the topic was based on something that John had written on his site. So maybe it’s time that I addressed this issue on my own.

My Background


I have one small bit of personal practical experience with video surveillance systems dating from about 2004. I was on a plant security committee that was directed to work with a contractor on installing a video surveillance system at the specialty chemical facility where I worked. This was post-911 and pre-CFATS so there was no regulatory guidance or requirements that we had to deal with; management had decided that we needed some sort of video surveillance to enhance the security at our plant.

Looking at Camera Placement


We quickly looked at the budget we had available and it was quickly clear that we would not be able to set up a system to observe the facility perimeter since we could only afford about a half-dozen point-tilt-zoom (PTZ) cameras. We only had two storage tanks that contained chemicals with potentially significant off-site effects so we decided that those were our possible terrorist targets. We also decided that, since an accidental release was more likely at our facility than a terrorist attack, we wanted camera locations that would be of help in our response to that type of incident.

Our major toxic release hazard was stored in a stand-alone tank farm alongside the rail-spur within the fence line; that spur usually had at least one full railcar of the same high-risk chemical parked next to the tank farm. A nearby pipe-bridge provided an ideal vantage point for observing that tank farm, the rail spur and the rail gate at the backend of the property. We also included appropriate lighting for that area in our plan.

Our other toxic release chemical storage tank was in the middle of a small tank farm with about twenty storage tanks. Try as we might we couldn’t find camera location that would allow us to see more than a small section of the tank. Since the EPA worst-case-scenario for that tank only barely included an off-site release we opted instead for coverage of the off-loading facility where tank wagons of that (and other hazardous chemicals) were off-loaded into the tank farm.

Two operational vehicle-gates were obvious areas where we wanted video surveillance coverage as was the area where we parked tank wagons waiting for unloading or for pick-up of their full loads for transport.

Observation


Video surveillance systems are worthless unless someone is watching them. Our five cameras were hard wired into a system with two dedicated monitoring stations with controls for the operation of the cameras. One was at the front gate where we had our single security guard working eight-hours a day. The other was in the plant control room that was operational 24/7.

Finally, software was installed in the plant manager’s computer, the production manager’s computer and in a computer located in another building on the site that was well separated from the production area. All three of these computers were connected to the system via the company intranet and each had a priority override for the controls for the operation of the cameras. These access points were designed more for safety and emergency response purposes than for security.

Use


We never did have a security incident at the plant while I worked there so the system was never really used as part of the counter-terrorism security system. Management did use one of the gate camera feeds in a termination case to document an employee’s unauthorized absence from the plant. One small spill response incident was followed on the video system and it really helped in the after action review for that incident. Other than that it was somewhat useful as a tool for supervisors to keep track of employees and provided some amusement for people in the control room.

Is this a typical installation? I really don’t know, but I suspect that it has many things in common with many smaller chemical facilities. Low budgets and complex facility layouts are going to be two factors that are going to come into play into many of these facilities. Environmental, health, safety and security (EHSS) managers are going to have to leverage their safety considerations and budgets to make these video surveillance installations worthwhile. If they can merge the coverage with areas that are of concern to operations, then the facility may be able to have a video surveillance system that covers a significant amount of the areas of security concern.

Sunday, October 14, 2012

S 3414 May Still Be Alive - Cybersecurity


Two different news organizations (TheHill.com and RollCall.com) are reporting that Sen. Reid (D,NV) is planning on bringing cybersecurity legislation back to the floor of the Senate when the body returns for their lame-duck session after the election. As I noted in August, Reid can call for reconsideration of the cloture vote on the bill at any time that he feels that he has the votes.

Legislation vs Executive Order


Both articles tie the Reed statement to the recent speech by the Secretary of Defense warning of a cyber Pearl Harbor attack. That statement follows recent news reports that the Administration was consulting with Congress and the business community on possible provisions for an executive order on cybersecurity for critical infrastructure. It seems likely that all of these events are tied together in a plan to provide the government the authority to regulate cybersecurity.

The politics of cybersecurity legislation are complicated. First, the regulatory authority that the Administration claims is necessary to protect this country against cyber-attacks by nation-states, terrorists, or even criminal organizations can only be provided by legislation. An executive order would provide only limited authority to expand regulations in only a few industrial sectors; other sector regulations would have to be based upon voluntary compliance.

Election Calculus


Cybersecurity legislation is clearly not a presidential election issue; neither side has made any attempt to make significant political capital taking a stand on the issue. President Obama is hardly likely to publish an executive order before the election for fear of offending some of his ‘civil liberties’ supporters who object to information sharing provisions supported by the Administration.

The Administration has a slim majority of support in the Senate for S 3414, but not enough as currently crafted to be able to get past a cloture vote. An agreement on allowing votes on some key amendments may change enough votes may provide a 60 vote margin to bring the bill to a vote; a vote that would probably lead to passage of the bill in the Senate. Passage of the bill in the House, as currently written, is almost impossible; the House cybersecurity legislation religiously avoids regulating industry beyond enabling some limited information sharing provisions that require nothing of industry.

The election next month may change the calculus in both bodies of Congress. If Democrats get closer to a supermajority (a clear supermajority does not currently seem to be a possibility) in the Senate, current opposition to S 3414 may be reduced by some departing members wishing to have at least some influence on cybersecurity legislation. If the Republicans, on the other hand gain seats (especially if they break the 50 vote barrier) in the election, the Democrats will have to surrender a lot of their desires to get S 3414 passed. The agreement would have to be for more than just votes on amendments; some of the mandatory provisions would have to be changed to voluntary. Which provisions would have to be changed would depend on the number of new Republicans reporting in January and which Democrats won’t return.

The House is much more complicated. Just about the only thing that will cause a wholesale change in the approach of the Republican leadership is if they lose control of the House in the election. Any other election outcome ensures that the current leadership will at the very least have a veto power over any cybersecurity legislation that heads towards the President. Any lame-duck Senate bill will have to take this into account.

Executive Order


Any effective executive order by President Obama will have to be proceeded by an election win. A President Romney would simply sign an executive order vacating one issued by Obama long before any effective action could be taken under such an order.

An Obama win would still not ensure that an executive order would have much of an effect on cybersecurity. To be effective the administration has to write regulations that have to go through the publish and comment process. This Administration has a poor record of writing regulations, particularly in the homeland security realm. A two-year old executive order harmonizing controlled unclassified information (CUI;  Executive Order 13556) has yet to produce any regulations changing the handling of such information. That regulation would only really affect executive branch politics, not business operations; that should make it an easier sell politically.

The Administration would also have to take into consideration that any regulations that have a substantial effect on business operations would certainly face litigation on the grounds of overstepping federal authority. Even just increasing cybersecurity controls over already regulated industries would certainly face such law suits. Extending such regulations to currently unregulated industries would be a non-starter just because of the threat of law suits. It has been made clear that even information sharing rules are likely to be opposed on privacy and free speech grounds.

Way Forward


There is a possibility that the Obama Administration could craft, with the help of the Republican leadership in the House a minimalist cybersecurity bill modeled on the House passed HR 2096. The House might acquiesce to limited cybersecurity regulations on the electric industry; the one industry that almost everyone has been mentioning as being at risk (shows how ‘everyone’s’ imagination is so limited). If they can get the House Republicans onboard, then they can probably convince the Senate.

One thing that all of the politicians have just about missed in their discussions is that there is a significant difference between IT and ICS cybersecurity. Any bill that really tries to address critical infrastructure cybersecurity must clearly differentiate between the two and write specific requirements for both types of security programs.

Saturday, October 13, 2012

Another Short Notice NIAC Meeting


DHS has posted a meeting notice in Monday’s (available on-line today) Federal Register (77 FR 62521-62522) announcing yet another short notice meeting of the National Infrastructure Advisory Council on October 16th, 2012 in Washington, DC. The Council will receive and discuss a presentation by the Regional Resilience Working Group.

Delayed Notification


The notice states that: “The Federal Advisory Committee Act requires that notices of meetings of advisory committees be announced in the Federal Register 15 days prior to the meeting date.” That’s not entirely true the Act states {§10(a)(2)} that:

“Except when the President determines otherwise for reasons of national security, timely notice of each such meeting shall be published in the Federal Register, and the Administrator shall prescribe regulations to provide for other types of public notice to insure that all interested persons are notified of such meeting prior thereto.”

I’ll accept that 15 days is ‘timely notice’, but I doubt that anyone would believe that 1 day (officially this notice isn’t published until Monday) constitutes timely notice of a physical meeting (as opposed to a teleconference). Even four days (it was published on the Federal Register Inspection page on Friday) doesn’t come close to constituting ‘timely notification’ by anyone’s definition.

Now, what is the ‘reasons of national security’ that allows the avoidance of the ‘timely notification’ requirement? The notice states:

“This notice of the NIAC meeting is published in the Federal Register with less than 15 days notice due to the complexity of the issues within the current study. Due to the complexities, the NIAC Working Group was not able to complete the interim finding of the report within this aggressive time line. Waiting for the full 15 day notice period to conduct the meeting will delay the discussion of the report. In order to not delay the continuation of this important study, this meeting is being announced with less than 15 days notice.”

I certainly see the national security tie there (Severe Sarcasm Warning).

The Presentation


According to the notice this meeting is to receive a presentation “from the NIAC

Regional Resilience Working Group documenting their work to date on the Regional Resilience Study”. This will not be a final report, just a report on work in progress. The notice goes on to explain that “The presentation will be posted no later than one week prior to the meeting [emphasis added] on the Council's public Web page on www.dhs.gov/NIAC.”

Well, the presentation is there as of 07:00 EDT, but JQ Public cannot access it. We just get an “Access Denied” message (“You don't have permission to access ‘http://edit.dhs.gov/sites/default/files/publications/NIAC%20niac-region-resile-wg-presentation-2012-10-16_1.pdf’ on this server.”). I suppose that Council members and DHS staff and other special people have access to the document as well as to the following documents listed on the NIAC web page as being “meeting resources”:



Note that neither of these is listed in the Federal Register notice about the meeting.

Public Comment


The Federal Advisory Committee Act requires that {§10(a)(3)}:

“Interested persons shall be permitted to attend, appear before, or file statements with any advisory committee, subject to such reasonable rules or regulations as the Administrator may prescribe.”

The notice does state that “we are inviting public comment on the issues to be considered by the Council as listed in the SUMMARY section below. Comments must be submitted in writing no later than October 11, 2012 [emphasis added]”. I’ll get my time machine out so that I can get these comments in in a timely manner (More Sarcasm). Fortunately, persons who wish to make oral comments to the Council have until 15 minutes prior to the start of the meeting to register their intent to speak.

I’ll provide the pro forma details for submitting written comments; comments may be submitted electronically via the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2012-0056).

Reality Check


Okay, I’ll admit that in the great scheme of things, even in the not-so-great Washington scheme of things, this meeting is a non-issue. The final report of this working group will not be issued until sometime next year, so this meeting is just a chest-beating exercise to allow Under Secretary Beers and supporting NPPD politicians to ‘give direction’ to NIAC big shots. Even the final report will be a relative non-issue, rating just short news reports read by Washington insiders and quickly forgotten.

The larger issue here is that DHS is flaunting their refusal to play by the rules. There is absolutely no reason that this meeting could not have been held on October 30th or later; allowing for the 15-day notice. But the current political management at DHS would rather ignore the rules to make themselves seem more important than they really are. And that is sad because they do hold important positions in the government, and they do wield a certain amount of political power. That they have to stoop to such petty political gamesmanship is a commentary on their political ineptitude.
 
/* Use this with templates/template-twocol.html */