SBInet, DHS Secure Border system

Just replace some of the names and you feel like your in the Middle East, where projects are known to be delayed, technology is always ahead of what was originally planned and the overall cost is several times higher then originally planned….

Important aspects of SBInet remain ambiguous and in a continued state of
flux, making it unclear and uncertain what technology capabilities will be
delivered, when and where they will be delivered, and how they will be
delivered. For example, the scope and timing of planned SBInet deployments and
capabilities have continued to change since the program began and, even now,
are unclear. Further, the program office does not have an approved integrated
master schedule to guide the execution of the program, and GAO’s assimilation
of available information indicates that the schedule has continued to change.
This schedule-related risk is exacerbated by the continuous change in and the
absence of a clear definition of the approach that is being used to define,
develop, acquire, test, and deploy SBInet. The absence of clarity and stability in these
key aspects of SBInet impairs
the ability of the Congress to oversee the program and hold DHS accountable for
program results, and it hampers DHS’s ability to measure program progress.

SBInet requirements
have not been effectively defined and managed. While the program office
recently issued guidance that defines key practices associated with effectively
developing and managing requirements, such as eliciting user needs and ensuring
that different levels of requirements and associated verification methods are
properly aligned with one another, the guidance was developed after several key
activities had been completed. In the absence of this guidance, the program has
not effectively performed key requirements definition and management practices.
For example, it has not ensured that different levels of requirements are
properly aligned, as evidenced by GAO’s analysis of a random probability sample
of component requirements showing that a large percentage of them could not be
traced to higher-level system and operational requirements. Also, some of SBInet’s operational
requirements, which are the basis for all lower-level requirements, were found
by an independent DHS review to be unaffordable and unverifiable, thus casting
doubt on the quality of lower-level requirements that are derived from them. As
a result, the risk of SBInet not
meeting mission needs and performing as intended is increased, as are the
chances of expensive and time-consuming system rework.

SBInet testing
has not been effectively managed. For example, the program office has not
tested the individual system components to be deployed to the initial
deployment locations, even though the contractor initiated integration testing
of these components with other system components and subsystems in June 2008.
Further, while a test management strategy was drafted in May 2008, it has not
been finalized and approved, and it does not contain, among other things, a
clear definition of testing roles and responsibilities; a high-level master
schedule of SBInet test
activities; or sufficient detail to effectively guide project-specific test
planning, such as milestones and metrics for specific project testing. Without
a structured and disciplined approach to testing, the risk that SBInet will not satisfy user
needs and operational requirements, thus requiring system rework, is increased.

Seriously, long term, highly technological projects always risky to manage. In a way, I admire those that can manage a project with hundreds and thousands of dependencies, external controls, budget constrains and eventually deliver a solution. I am sure that under the proper guidance, this said system will become the cornerstone of the border control system.

]]> http://securitypie.com/you-dont-build-a-fence-this-way/feed/ 0 http://securitypie.com/federal-regulations-mandates-protection-of-private-sector-data/ http://securitypie.com/federal-regulations-mandates-protection-of-private-sector-data/#comments Thu, 18 Sep 2008 05:38:10 +0000 sharon http://securitypie.com/?p=87 Here’s some very interesting reading material. I must admit that I was not aware of all the Federal policies to govern and protect IT systems and data in private sector companies. Below you can read the summary of the United States Government Accountability Office GAO-08-1075R.

More important, this document lists some of the penalties and enforcement options that the Feds can use.

Summary of Federal Requirements for Securing Privately Owned IT Systems and Data

Federal policy identifies 18 infrastructure sectors–such as banking and finance, energy, public health and healthcare, and telecommunications–that are critical to the nation’s security, economy, public health, and safety. Because these sectors rely extensively on computerized information systems and electronic data, it is crucial that the security of these systems and data is maintained. Further, because most of these infrastructures are owned by the private sector, it is imperative that public and private entities work together to protect these assets. The federal government uses both voluntary partnerships with private industry and requirements in federal laws, regulations, and mandatory standards to assist in the security of privately owned information technology (IT) systems and data within critical infrastructure sectors. As agreed, our objectives were to (1) identify, for each critical infrastructure sector, the federal laws, regulations, and mandatory standards that pertain to securing that sector’s privately owned IT systems and data and (2) identify enforcement mechanisms for each of the above laws, regulations, and mandatory standards.

There are at least 34 federal laws, regulations, and mandatory standards that pertain to securing privately owned IT systems and data in our nation’s critical infrastructure sectors. Of the 34, 1 is a law, 25 are regulations, and 8 are mandatory standards. These requirements pertain to 10 of the 18 critical infrastructure sectors, including the agriculture and food; energy; nuclear reactors, materials, and waste; and transportation systems sectors. Each of the 34 federal legal requirements has at least one enforcement mechanism. These mechanisms include court injunctions, civil monetary penalties, criminal penalties, and administrative actions, such as license revocation and suspension. Typically, these mechanisms are what agencies use to enforce requirements in general, and are not necessarily specific to the requirements for securing privately owned IT systems and data.