Showing posts with label SAFETY Act. Show all posts
Showing posts with label SAFETY Act. Show all posts

Monday, October 13, 2025

S 2551 Introduced – SAFETY Act Extensions

Back in July Sen Peters (DMI) introduced S 2551, the Extending Anti-Terrorism Protections Act of 2025. The bill would authorize DHS to temporarily extend the duration of protections provided under the system of risk management set forth in the Support Anti-Terrorism by Fostering Effective Technologies (SAFETY) Act of 2002. No new funding is authorized.

Moving Forward

Peters is a member of the Senate Homeland Security and Governmental Affairs Committee to which this bill was assigned for consideration. This means that there may be sufficient influence to see the bill considered in Committee. Generally, I see nothing in this bill that would engender any organized opposition. Having said that, I would not be surprised to hear that Chairman Paul opposed the bill, which would effectively kill consideration of the measure. I suspect that there would be some level of bipartisan support for the bill in Committee, but probably not enough to carry it to the floor under the unanimous consent process.

Sunday, January 26, 2025

Review – ChemLock and Risk Based Performance Standards

This is part of a series of blog posts looking at the potential for the authorization of CISA’s existing ChemLock program and using it as a voluntary replacement for the now defunct Chemical Facility Anti-Terrorism Standards (CFATS) program. Other posts in this series include:

CFATS is Dead,

Making ChemLock Safety Act Compliant – ChemLock Program Background,

ChemLock and Tiering,

Reader Comment – TSDB Screening for ChemLock,

ChemLock and TSDB Screening.

NOTE: Earlier articles in this series have been removed from the CFSN Detailed Analysis paywall and are available to the public.

One of the key concepts upon which the CFATS program was founded is that the diversity of chemical facilities makes it nearly impossible to establish a security program which would fit each and every facility. So, when the CFATS regulations were written, DHS attempted to describe the outcome that they wanted to see from facility security programs rather than mandate what security measures facilities would be required to use. These risk based performance standards (RBPS) were codified at 6 CFR 27.230. Any authorization of the ChemLock program should direct CISA to take the same tack in making the program Safety Act (6 USC 441 et seq) compliant.

The current ChemLock security goals, properly fleshed out, could easily become the basis for a quasi-regulatory scheme by which facilities could be judged to be eligible for SAFETY Act protections. A version of the CFATS RBPS Guidance document would have to be created, tailored to the six security goals included in the updated ChemLock program and the proposed 5 risk tiers proposed in my earlier posts.

Sunday, January 19, 2025

ChemLock and TSDB Screening

This is part of a series of blog posts looking at the potential for the authorization of CISA’s existing ChemLock program and using it as a voluntary replacement for the now defunct Chemical Facility Anti-Terrorism Standards (CFATS) program. Other posts in this series include:

CFATS is Dead,

Making ChemLock Safety Act Compliant – ChemLock Program Background,

ChemLock and Tiering, and

Reader Comment – TSDB Screening for ChemLock.

NOTE: Previous articles in this series have been removed from the CFSN Detailed Analysis paywall.

TSDB Screening

One of the more controversial elements of the CFATS program was the personnel surety process. Part of the risk based performance standards outlined in 6 CFR 27.230, DHS required facilities to perform “appropriate background checks on and ensure appropriate credentials for facility personnel, and as appropriate, for unescorted visitors with access to restricted areas or critical assets”. Three of the four requirements under this paragraph {§27.230(a)(12)} are relatively standard background checks performed by many businesses. The fourth requirement {§27.230(a)(12)(iv)} was more problematic: “Measures designed to identify people with terrorist ties”.

The only relatively comprehensive data base that could be used to satisfy that requirement is the Terrorist Screening Database (TSDB) maintained by the Transportation Security Administration (TSA). Unfortunately for the CFATS program, employers do not have access to the TSDB, even for the purposes of vetting employees at designated high-risk facilities.

ChemLock and Screening

There is currently no process within CISA’s voluntary chemical security program, ChemLock, that facilities could be used to conduct a similar TSDB screening process. One of the main reasons for this is that Congress needs to specifically authorize non-governmental use of the TSDB since much of the information included in the database comes from classified sources.

As part of the congressional authorization of the ChemLock program that I am advocating for here, Congress should include in that authorization the authority for CISA to process data from chemical facilities for screening against the TSDB. Since the ChemLock program is voluntary (and will have to remain that way if there is any chance for it to be authorized in the current congressional climate) the screening of employees for terrorist ties would also have to remain voluntary.

Having said that, as part of the Safety Act (6 USC 441 et seq) tie-in that I am arguing for here, facilities that are attempting to get Security Act certification from CISA would have to conduct TSDB vetting as part of the pre-requisite for that certification. Who would have to be vetted would be directly tied to the Tier ranking that I discussed in a previous post. Facilities would be allowed to identify specific chemical security zones within the facility, and anyone being authorized unaccompanied access to those zones would be required to have been vetted through the TSDB. Facilities identified as being at a Tier 5 (the lowest threat level, not previously covered by the CFATS program) would only be authorized to vet a limited number of people in critical positions described in their site security plan.

 

For more information on the TSDB screening issue, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/chemlock-and-tsdb-screening - subscription required.

Thursday, January 2, 2025

Review - Making ChemLock Safety Act Compliant – ChemLock Program Background

Earlier this week, in my post “CFATS is Dead” I suggested that Congress needs to authorize CISA’s ChemLock program to protect it from the budget cutters. The reason being that without the Chemical Facility Anti-Terrorism Standards (CFATS) program, there is no broad federal program to help the chemical industry to protect itself from potential terrorist attacks. And news reports from the early morning of January 1st reinforce the idea that terrorists still have an interest in attacking the United States.

In that earlier piece, I go on to explain, that as an incentive for chemical facilities to participate in the voluntary ChemLock program, Congress should provide in the program authorization automatic Safety Act (6 USC 441 et seq) protections for participating facilities, noting:

“The legislation authorizing the establishment of the ChemLock program could authorize DHS to declare that any facility that employs a minimum level of security measures defined under the program to have employed qualified anti-terrorism technology under the Safety Act and thus eligible for risk management and litigation management protections of the Act.”

In this series of posts, I would like to look at what that term “employs a minimum level of security measures defined under the program” could look like. Let’s start by looking at the existing ChemLock program.

ChemLock

The existing ChemLock program was established in November 2021. It provides chemical facilities with a wide range of resources to help them identify and mitigate their chemical facility security risks. These include:

ChemLock Resources,

ChemLock Exercises,

ChemLock Training, and

Special Access to Other CISA Services

But, most importantly for this discussion, ChemLock provides On-Site Assessments and Assistance. CISA’s Infrastructure Security Division notes that:

“Using CISA’s extensive knowledge of chemical security best practices, CISA chemical security personnel under the ChemLock program can provide on-site assistance and assessments that help facilities identify the specific security risks their on-site chemicals present and offer scalable, tailored suggestions for security measures that will best enhance their security posture based on their unique circumstances and business model.”

 

For more information on the current ChemLock program, including links to publications, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/making-chemlock-safety-act-compliant - subscription required.

Friday, February 23, 2018

S 2392 Introduced – Cybersecurity Technology


Earlier this month Sen. Daines (R,MT) introduced S 2392, the Cyber Support for Anti-Terrorism by Fostering Effective Technologies (Cyber SAFETY) Act of 2018. The bill would extend the protections of the SAFETY Act (6 USC 441 et seq) to cybersecurity technology in addition to the existing protections for anti-terrorism technology.

SAFETY Act Background


The DHS Science and Technology Directorate administers the SAFETY Act and describes it on their web site this way:

“The SAFETY Act provides incentives for the development and deployment of anti-terrorism technologies by creating systems of risk and litigation management. The purpose of the Act is to ensure that the threat of liability does not deter potential manufacturers or sellers of effective anti-terrorism technologies from developing and commercializing technologies that could save lives.”

After appropriate review of proposed technologies {see 6 USC 441(b)}, the Secretary certifies an anti-terrorism technology {“any product, equipment, service (including support services), device, or technology (including information technology) designed, developed, modified, or procured for the specific purpose of preventing, detecting, identifying, or deterring acts of terrorism or limiting the harm such acts might otherwise cause”; 6 USC 444(1)} as qualified anti-terrorism technology. When that qualified technology is employed in response to an act of terrorism, the seller/provider of that technology is provided some protections against 3rd party liability claims resulting from the approved use of the technology.

Amendments to SAFETY Act


The bill would make a number of amendments to the existing language of the SAFETY Act. Most of those changes consist of adding the words “cybersecurity” or “qualifying cyber incidents” in places in the Act which make reference to “anti-terrorism” or “acts of terrorism”.

There is only one definition supplied by this bill; adding the term “qualifying cyber incident” to the list of definitions in §444. That new definition applies the definition of ‘incident’ from 44 USC 3552(b)(2). That definition is a very IT centric definition that applies to any occurrence that “actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system” {§3552(b)(2)(A)}. It also specifically includes “a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies” {§3552(b)(2)(B)}.

Moving Forward


Daines is a relatively low-ranking member of the Senate Homeland Security and Governmental Affairs Committee to which this bill was assigned for consideration. This means that he may have enough influence to have this bill be considered in Committee.

I do not see anything in this bill that would engender any significant opposition. If the bill were to be considered in Committee, it would probably pass with bipartisan support as it would if it were to ever reach the floor of the Senate.

Commentary


While the provision for limited protections against 3rd party liability claims for qualifying cybersecurity technology certainly has its merits, there are a couple of very serious problems with this bill. And those deal with definitions, both those that are missing and those that are lacking.

The most glaring problem with the bill is the lack of a definition of ‘cybersecurity’ or more importantly ‘cybersecurity technologies’ as the term is usually used in the proposed revision to the SAFETY Act. The definition of ‘qualified anti-terrorism technology’ can help provide a framework for a definition once we add terminology appropriate to ‘cybersecurity’. I would propose that the following definition be added at the end of the bill:

“(8) CYBERSECURITY TECHNOLOGY – The term “cybersecurity technology” means any product, equipment, service (including support services), device, or technology (including information technology) designed, developed, modified, or procured for a cybersecurity purpose as that term is defined in 6 USC 1501(4).”

That ‘cybersecurity purpose’ term, in turn, relies on the expansive definition of ‘information system’ in §1501(9) that specifically includes industrial control system components. Thus, the ‘cybersecurity technology’ would also encompass ICS protections, which are mostly missing from this bill.

The other major problem with definitions in this bill is the definition of “qualifying [emphasis added] cyber incident” does not include any mention of a requirement for the Secretary to designate an incident as a ‘qualifying cyber incident’. Thus, any incident meeting the IT centric and very expansive definition in §3552(b)(2), would, a priori, be a ‘qualifying cyber incident’. This could easily be rectified by changing the wording of the definition to:

“(7) QUALIFYING CYBER INCIDENT –

(A) The term “qualifying cyber incident” means any incident, as that term is defined in section 3552(b) of title 44, United States Code, that the Secretary determines meets the requirements under subparagraph (B), as such requirements are further defined and specified by the Secretary.

(B) REQUIREMENTS.— An act meets the requirements of this subparagraph if the act—

(i) is unlawful;

(ii) causes harm to a person, information system (as that term is defined in section 1501(9) of title 6, United States Code), property, or entity, in the United States, or in the case of a domestic United States air carrier or a United States-flag vessel (or a vessel based principally in the United States on which United States income tax is paid and whose insurance coverage is subject to regulation in the United States), in or outside the United States; and

(iii) uses a cybersecurity threat or malicious cybercommand and control as those terms are defined in section 1501(5) and (11) of title 6, United States Code.

Tuesday, October 2, 2012

DHS Publishes SAFETY Act ICR Renewal Notice


Today DHS S&T published a 60-day information collection request (ICR) in the Federal Register (77 FR 60130-60131) to renew the authority to collect public information in support of the Support Anti-Terrorism by Fostering Effective Technologies (SAFETY) Act Program. According to the notice the “SAFETY Act program promotes the development and use of anti-terrorism technologies that will enhance the protection of the nation and provides risk management and litigation management protections for sellers of Qualified Anti-Terrorism Technology (QATT) and others in the supply and distribution chain”.

The currently approved ICR expires on March 31st, 2013. The current request replicates the estimates of participation and burden provided in the current ICR; 950 annual requests and 17,300 hours of public action supporting those requests. The ICR covers the completion of 11 forms used in various parts of the application process that would be completed by business entities and associations, as well as State, Local and Tribal Government entities.

The public is invited to submit comments about this ICR renewal and may do so via the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2012-0043). Comments need to be submitted by December 3rd, 2012.

NOTE: There have been suggestions made that CFATS covered facilities could provide themselves with a certain amount of risk management and litigation management protection by registering their facility protective measures with this program. DHS has a secure web site (www.SAFETYAct.gov) that might be helpful in investigating this process. I’m not sure how that would work, but I would certainly be interested in hearing about any facility that attempts to do this.

Monday, August 20, 2012

A Closer Look at the Heritage Foundation Report – Four Principles


This is the second blog in a series taking a critical look at the recent Heritage Foundation report on the problems with the CFATS program. While the report authored by Jessica Zuckerman is not up to the usual editorial standards of the Heritage Foundation it does raise some interesting issues. The earlier blog post can be found here:


In this post I will be looking at the discussion in the Report under the heading of ‘Right in Principle, Wrong in Practice’. This section looks at the program from the perspective of how well the CFATS implementation has followed the four principles outlined by Under Secretary Beers in his March 30th, 2011 testimony before the House Homeland Security Committee (Oops, it was before the House Energy and Commerce Committee on March 31st, 2011 and the link provided in the report is bad, DHS web site change not Ms. Zuckerman’s fault there, but the rest is just poor scholarship).

Cross-Collaboration


Zuckerman properly points out that the individual facilities, the Federal government as well as State and local governments all have interests in securing high-risk chemical facilities. She then takes the CFATS program to task for centralizing the responsibility for security at the Federal level. She notes that:

“The government must determine facilities’ risk lev­els, set performance standards, and assess security plans and compliance.”

Congress provided in §550 that DHS was supposed to develop a security program targeted at just those chemical facilities that were determined to be at the high risk for terrorist attack. Furthermore, the program should be risk-based with the highest risk plants getting the earliest attention. All of these require DHS to determine facility risk levels.

The performance standards were published by DHS as one would expect since they would be judging if facilities met these performance standards in the implementation of their security plans. DHS developed the standards in conjunction with industry input and published a draft of the Risk-Based Performance Standards. Extensive industry comments were received on that draft (see my blog posts from 11-28-08, 12-05-08, 12-05-08, 01-09-09 and 01-13-09) and were taken into account when the final version was published.

Furthermore, DHS worked hand-in-hand with industry in developing, fielding and modifying the Top Screen and Security Vulnerability Assessment Tools. For both of these portions of the CFATS process the first ten or so facilities to complete submissions had DHS personnel on site in the information development and submission process to work out the inevitable bugs in the system. The lessons learned in those shared submission efforts were put into modifying the tools and documentation before those systems went live for the remainder of the CFATS community. That this was not done in the SSP submission process probably goes a long way to explain the problems in that system.

Ms. Zuckerman closes this section by claiming that:

“Enhancing chemical security does not mean that the private sector should yield its responsibil­ity to the federal government.” (pg 5)

Nowhere in her arguments does she show where the private sector has been required to yield its responsibility for the security of their facilities. The CFATS program does not specify how a security program should be put together, it simply provides standards by which the government will judge the success of that program. That those standards are vague at best is at least partially the responsibility of private industry. They were the ones that demanded performance based standards and complained about anything coming close to specifics in the draft version of the RBPS Guidance Document.

Risk-Based Tiering


Zuckerman takes DHS to task for not sharing the basis for the Department’s risk tiering process, a complaint that has been made a number of times over the years since the first NPRM was published for the CFATS regulations. Actually this complaint has been combined with the lack of openness about the process for establishing the ‘high-risk’ status of facilities in the first place.

The report properly notes that the details of the risk-ranking methodology is not shared with owners. This does not allow an owner to do more than to make a reasonable guess as to what actions the facility can take to have their Tier ranking lowered or even to be removed from the CFATS list all together. There is a process in place to submit information to have either the Tier ranking or CFATS listing reconsidered, but it is an iterative process at best.

While I agree with Ms. Zuckerman’s assertion in this case, she does her report ill service by not addressing, even in passing, the reasoning that DHS has used to avoid publicizing the details of their methodology. This lack of addressing opposing arguments is another of the reasons that this Heritage Foundation report is probably more useful as a political document than a real study of the issues involved.

Any discussion of the sharing of information about the security tiering or assessment process must take into account the official DHS response to such questions in the regulatory comment process. DHS outlines their position quite clearly in the preamble to the Interim Final Rule published in the Federal Register (72 FR 17700 – 17701).

Zuckerman also addresses the failure of DHS to share tiering information with State and local authorities; stating that:

“In addition, first responders and community leaders have also expressed concern about the lack of transparency of facility tiering and risk assessments, citing the fact that the lack of information sharing may impede emergency response and community preparedness.” (pg 5)

While one might suppose that State and local officials might want some input on the evaluation process of facilities within their jurisdiction, the claim of lack of transparency of the facility tiering and risk assessment process fails to address the efforts made to share that information with local authorities. DHS has made it clear that facilities have an inherent responsibility for coordinating with local emergency response officials and provides the State Homeland Security Directors with access to an online tool in CSAT to check on the CFATS status of chemical facilities within the State.

Finally, Ms. Zuckerman takes DHS to task for the problem it discovered last year in its risk model. While there should be some discussion on the internal delays in responding to the discovery of the model discrepancy, it really is disingenuous to complain about the problem with the model. Any researcher or academic knows that a model is only an approximation of reality and adjustments have to frequently be made to models to ensure their accurate reflection of reality. ISCD should be commended on monitoring their system closely enough to detect and correct the problem.

On an editorial note there are many claims of comments by unnamed industry or local government officials within this section. The footnotes to those claims almost uniformly point to the book “Chemical Facility Security” by Shea, but not a single page citation is provided. This is just another continuing example of the poor scholarship exhibited throughout this work.

Performance Standards


Zuckerman’s section on performance standards, or more appropriately the Risk-Based Performance Standards (RBPS) actually addresses the core issue of the current ISCD problems. She acknowledges that the theory behind the RBPS is good but notes that in practice “chemi­cal facilities have largely been left uncertain over what is expected of them in meeting the DHS’s stan­dards” (pg 6). Unfortunately, industry is largely to blame for these problems. They insisted on risk-based performance standards instead of concrete security measures and even convinced their politicians in Congress to prohibit DHS from specifying any security measure as being necessary for SSP approval.

As I noted earlier, when DHS published the draft of the RBPS Guidance document in October 2008, the industry comments came fast and furious. While many of the comments were constructive the vast majority were complaining that this or that was too specific and wouldn’t or shouldn’t apply to their industry or company. Once again DHS gave in to the political pressure (which is never mentioned in Ms. Zuckerman’s report), and produced a very vague RBPS Guidance document.

Ms. Zuckerman blames the problem, in part, on the Chemical Facility Security Inspectors (CFSI’s; oh, she never does use their proper title; a small thing to be sure); noting that:

“Similarly, issues in training and hiring capable and experienced inspectors has resulted in confusing and conflicting feedback from ISCD inspectors in the course of pre-authorization visits and authorization inspections.”

I’ll address the CFSI specific issues in a later post, but this complaint (not unique to Zuckerman) misses the important point. In the pre-authorization and Authorization inspections, the inspectors are just the eyes and ears of the ISCD staff. It is that staff (and frequently contractors) that never sees the facility that makes the decision on whether or not an SSP is approved or not. Thus, the person the plant talks to is not the person making the decisions.

DHS has tried to clarify this on a number of occasions, but I seriously don’t think that it has really gotten through to the folks in the inspected facilities. Thus this reported confusion in the field.  Oh by the way, Ms. Zuckerman provides no source for her comments about ‘confusing and conflicting feedback from ISCD inspectors’.

Leveraging Existing Advancements


This section of the report deals with the usage of ‘Alternative Security Plans’ or ASPs. Ms. Zuckerman falls into the same language trap that most people do when the discuss ASPs. When most of the chemical industry talks about ASPs they mean security programs like the American Chemistry Council’s Responsible Care Security program. This is a set of standards along with a third party verification of compliance for security related issues. When industry talks about ‘accepting’ such a plan it appears that they mean the facility should be given credit for that plan when they have been certified by the third party and DHS should accept that as an approved SSP.

DHS, on the other hand misnamed their SSP; it is not a site security plan. What the SSP is is a series of questions about the security set up at a particular facility to determine if that security program meets the requirements of the Risk-Based Performance Standards. DHS doesn’t care if the security measures are part of another certified site security plan; great, just so long as your answers to the questions show the facility meets the RBPS.

The problem is that ISCD does not have the time nor the manpower to read the documents associated with a real security plan; a 100+ page document with annexes describing emergency response, personnel surety, key control, etc. Adding a variety of formats from different security programs will only add to that problem.

Ms. Zuckerman manifests her misunderstanding of the problem by stating that:

“This lack of motivation on the part of the DHS to seriously consider ASPs inhibits the ability of compa­nies to continue to employ security measures in which they have already invested time and effort, thereby discouraging the innovation and creative thinking that have been critical to the security of the private sector in the past. As such, it limits the field of security options to those rigidly established by the federal government.” (pg 6)

Nothing that DHS is doing is limiting the ability of facilities to continue to use existing security measures, either to completely or partially fulfill their compliance with the 18 risk-based performance standards set forth in the CFATS regulations. And DHS is specifically prohibited from establishing rigid security options.

What industry really wants is for the currently established voluntary security programs to be accepted without review by DHS. In essence what they want is to have these third-party certification agencies to perform the inherently governmental function of examining and approving the security plan for CFATS covered facilities. Unfortunately, DHS has been given the responsibility for performing this function and does not have authority to transfer that responsibility to a private sector entity (okay, we’ll ignore for the moment that they are using contractors for the information processing necessary to make that decision; oh, that isn’t in the Heritage Foundation report).

In the closing paragraph in this section of the report Ms. Zuckerman brings up an interesting point that I must admit I haven’t seen mentioned in reference to the CFATS program. She mentions that “the department should encourage companies to apply for certification under the Support Anti-terrorism by Fostering Effective Technologies (SAFETY) Act of 2002”. Actually I have heard of the SAFETY Act program and I seem to recall that it is run by DHS S&T, not NPPD.

Still if NPPD could identify areas where new technology would benefit facilities covered under the CFATS program, it would certainly be helpful if a SAFETY Act program could be put together to fulfill that need. Okay, I’ll remake a suggestion here; chemical facility response forces need a weapon that can be used to stop violent attackers without posing a safety hazard when used within the high-risk environment of a chemical facility. Sorry that’s a pet peeve of mine and doesn’t really have anything to do with the review of this report. It won’t happen again.

Other Critical Concerns


This section deals with the issues raised in the so called Anderson memo that was made public last December. Ms. Zuckerman has had no more access to that memo than have any of the rest of us that have commented on the problems at ISCD. So I’ll give her a pass on all of the errors in this section as they are the same ones that just about everyone has made. She has no background working with this program so she can only repeat the same unfounded charges. See my blog post from last December on my reporting on the ISCD issues.
 
/* Use this with templates/template-twocol.html */