May 25, 2013

Quality by Design (QbD) Pilot Presents Industry With New Challenges

Patrick Stone, President, TradeStone QA

What products will be affected by QbD? It will apply to new Marketing Authorization Applications (MAAs)/New Drug Applications (NDAs), Type II Variations/Prior-approval supplements (sNDA) and Scientific Advice requests/CMC formal meeting request that include QbD/PAT elements and are submitted to FDA & EU new applications, for MAAs/NDAs where the sponsor/applicant has agreed to a parallel evaluation by both agencies.

Upon request from the sponsor/applicant, and where procedural time-lines will allow, Type II Variations/NDAs may also be considered on a case by case basis. Right now this is a voluntary pilot with some pharma companies being tapped or nudged by FDA & EMA to join in.

Our geographically diverse health product market involves more contracting and outsourcing for many product components. Finished product real time testing and design space requirements will be crucial for implementing QbD.  ICH third party QA mandates will result from this pilot program.

QbD products will be as unique as the individuals who receive them (personalized medicine). This new model may impact two-thirds of the new health care products in the pipeline (cell therapies, gene therapies, and molecular entity therapy).   There will be many approaches to high order characterization and some are not cost effective at present.  Many of the details will take years to sort out. Collaborations between the FDA, Japan Ministry of Health, and  European Medicines agency will require funding along with mutual scientific trust.

Emerging technologies and laboratory techniques will be required to accomplish the QbD paradigm shift. FDA can’t continue using the chemistry approval model for biotechnology products.  This paradigm shift may increase development times and cost structures.  The ICH model will also bring mandatory third party QA review so prepare your models for this as well.

Here are the essential points to focus on for QbD products:

  1. Target the product profile,
  2. Determine CQAs (Critical Quality Attributes),
  3. Link raw material attributes and process parameters to CQAs,
  4. Risk assessment,
  5. Develop a design space,
  6. Design and implement a control strategy.

Generic Drug TabletThe biotechnology sector QbD product development focus will be on design space and real time release testing. The pilot discussion focus for both regulatory agencies will be on ensuring consistent implementation of ICH Q8, Q9, and Q10 guidelines in the assessment process and to facilitate sharing of regulatory discretion & new regulatory concepts manufacturers of small-molecule generic drugs have concerns the initial lag-time in course correcting for the QbD initiative may exponentially delay the application file time for their products.

It appears some generic-drug manufacturers are not willing to implement any QbD concepts until closer to final harmonization and discussion time frames.

Why do you need higher order structure modeling?  Higher order structure product applicants will have to provide protein folding kinetics models with characterization integration into the application and annual report.  Your research models and early development modeling may be progressed for this function. Personalized medicine with batch to batch consistency including stability of 1-90 days is recommended. There are also talking points about including variants and aggregates of your products in the higher order structure models.  Intra and inter chain disulfide bonding, aggregation, and complete polypeptide modeling may be requested application material.

This may prove to be more cost effective while two juggernauts (FDA & EMA) iron out the red tape that will flow from this type of global initiative.  If the funds necessary to make this effort progress are not available on the FDA or EMA, side delays in the process are inevitable.

Molecular and personalized medicine can’t continue to be reviewed with the FDA chemical entity systems approach, approval model.   Effective cancer therapies and molecular medicine may not have the statistical significance necessary when only a handful of patients are treated with the cell or gene therapy.

Warning to Industry: FDA will obviously not let you have your cake and eat it too.  Innovate inevitable change by comments to FDA or accept the QbD change that is inevitable.   Your comments to the FDA will be monitored on the FDA’s Facebook page and current open comment requests. Contact your respective FDA liaison or center contact for discussion points directly related to your product.

Patrick Stone is the author of Bubble Gum Badge – An FDA His-Story. You can also follow him on Twitter.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

How to Handle NERC’s Risk-Based Reliability Compliance Monitoring

Vice President, Energy & Utilities Compliance, AssurX Inc.

As the Electric Reliability Organization (ERO) enters it’s fourth year as a mandatory entity, NERC and the Regional Entities have been working with the registered entities, FERC, and other stakeholders to improve reliability.  One of the latest topics being discussed at reliability workshops and meetings is the implementation of Risk-Based Reliability Compliance Monitoring.  What does this mean to a registered entity and how best to prepare for this change?

NERC and the Regional Entities have gathered enough data over the last four years to start the assessment to develop a risk-based reliability program.  Many mature industries have adopted the same type of approach in the past.  NERC has started to identify the core set of critical reliability standards to be audited and what areas are most crucial for reliability.  NERC has also been working over the years to assist registered entities on how to build strong compliance programs and what it takes to implement a culture of compliance within an organization.

NERC has identified some of the criteria to start developing a Risk-Based Reliability program, they include:

  • NERC top 20 list of allegedly violated reliability standards
  • High Violation Risk Factor (VRF)
  • Violation Risk Index (VRI)
  • Past reliability events and major reliability issues
  • Input from Regional Entities; especially from the audit teams and enforcement groups
  • Assessment of registered entities compliance program and compliance culture

Some Regional Entities are developing their own Compliance Surveys that will be sent out to their registered entities.  AssurX Compliance Services division has developed a white-paper outlining some of the key issues an organization should focus on to build an internal culture of compliance.  As the ERO matures, more attention should focus on sharing lessons-learned from events, improving critical reliability standards, and how a registered entity mitigates identified issues.

We will be writing more about the Risk-based Reliability Compliance monitoring program in future weeks.  Review our white-paper and contact us if you have more questions.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Fact, Fiction or Just Good Old Fashioned Nonsense – EMP Speech From FERC Conference

James Holler, Founder, Abidance Consulting

On February 8, 2011, FERC hosted a conference dealing with the security of the nation’s grid. I really wish I had been there so I could have called a lot of these people on the carpet about the garbage they were spewing forth! One of the “Chicken Little’s” that took time to try and scare people, Avi Schnurr of the Electric Infrastructure Security Council (EISC), gave a doomsday scenario without any language on how to prevent or recover from an EMP event.

If Mr. Schnurr had wanted to add any value to his speech, which by the way, was based on test data from 45-50 years ago, he would have stated that there is a fix for EMP events called a Faraday Shield. Mr. Schnurr could have continued on and told everyone that Faraday Shields are so common that they are used in everyday items such as cell phones, microwave ovens and even LCD televisions. The technology to fix the issue(s) stated by Mr. Schnurr has been around for more than 50 years.

When an individual or company gives you bad scenario after bad scenario of what will, and not what might occur, and not give a single example of a solution of even a hint of a solution, one should ask themselves what is this person’s ulterior motive?

It is solely my opinion that the only purpose Mr. Schnurr served was to scare the power industry into calling on the EISC for assistance — for a hefty fee I am sure. I could be wrong, but I doubt it. I have seen too many “snake oil salesmen” in my time.

James Holler is founder of Abidance Consulting.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

How Risky is Risk for FDA-Regulated Life Sciences Companies?

Russ King, Managing Partner, Methodsense

The simple word “Risk” is certainly one of the most frequently used terms in the contemporary Compliance Lexicon. It has become a cliché to say that the FDA advocates a “risk based approach.” Risk Management, Risk Assessment and Risk Mitigation are staples on the menus of virtually every life science conference and exhibition. Life Science publications behave similarly and as a case in point the tag line of the AssurX Blog site is “Compliance, quality and risk: Straight talk for regulated industries” (emphasis mine).

But what the heck is “risk”? Should the very nature of “risk” in and of itself really matter to life science companies on a level beyond scenarios of potential harm, SOP creation and record generation?

First, the (sophomoric) exercise of reviewing alternative definitions of risk to get us started:

  • risk = an unwanted event which may or may not occur.
  • risk = the cause of an unwanted event which may or may not occur.
  • risk = the probability of an unwanted event which may or may not occur.
  • risk = the statistical expectation value of an unwanted event which may or may not occur.
  • risk = the fact that a decision is made under conditions of known probabilities (“decision under risk” as opposed to “decision under uncertainty”)

All of these definitions, as well as others, have a couple of things in common: risk involves unwanted consequences and uncertainty. Obvious, right? (Remember this was a sophomoric exercise). Nevertheless, it is interesting to note that unwanted consequences and uncertainty are something we humans tend to fear and hate. Uncertainty is also generally unpopular with humans.

Now consider this within the context of a medical device, pharmaceutical or biotechnology company. Among the passions driving life science companies is scientific knowledge (humans love knowing) and the practical execution of knowledge on behalf of at least two other passions: improving the length and quality of our lives (something humans generally endorse on a wholesale basis) and economic success (a value that is a tad more controversial, but still generally endorsed by most of us). Not surprisingly, these two values are intimately connected: if a life science company can successfully improve our lives, we tend to be willing to pay for it.

Recall now that element of risk called ‘uncertainty’. Uncertainty seems to be diametrically opposed to knowledge, a core value of a science based endeavor. Uncertainty seems at cross purposes to the other passions of life science companies. There is nothing like the uncertainty about the performance of devices or drugs to keep them out of the market or drive buyers away. (But isn’t that the way things should work?)

How a life science company responds to uncertainty will tell you a lot. We have seen fear, fearlessness, dissembling behavior, aggressive truth seeking….you name it and everything in between.

Uncertainty has the powerful ability to threaten everything built by the driving passions of a life science company from market share to profitability. No wonder the reactions to uncertainty vary so greatly from organization to organization. But there is something special about uncertainty and the advocacy of a risk based approach that should be strongly embraced by life science companies.

Confronting and overcoming uncertainty means that at a level much deeper than SOPs and Quality Records we gain knowledge, the very kind of knowledge that fuels the passions of contributing to our welfare and success. Assessing and understanding risk, managing risk and mitigating risk accomplishes this by delivering a better understanding of a company’s products, their manufacture, new products, better operations, etc. which invariably creates greater opportunities to improve our lives and enhance our wealth.

Yes, peeling back the veil of uncertainty can reveal the possibility or even the probability of unwanted consequences. It is very difficult to keep the ‘bad’ out of everything. But the strength of successful life science companies comes from what they know, when they know it, and what they do with that knowledge. The more skillfully life science companies look for, root out, and drag risks into the appropriate (not just any) well lit forum, the more uncertainty is condemned to understanding. Consequently, the opportunity to forestall the possibility or reduce the probability of unwanted consequences improves dramatically.

In other words, risk is a lot more risky if you take the risk of not facing it.

Russ King is Managing Partner at MethodSense, Inc.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Balance of “Spirit,” “Letter” of Life Sciences FDA Regulations Key to Compliance

Russ King, Managing Partner, MethodSense

While on a recent vendor audit of a contract research organization (CRO) we observed a situation we see over and over in this industry: Our client, the sponsor, was looking for compliance within the “spirit” of the regulations. But the CRO’s understanding of regulatory obligation was much narrower and driven by a strong emphasis on “procedures” which was principally informed by ICH E6 and their experience from relatively short one to two day audits by their clients / Sponsors: The CRO was seeking to comply with the “letter” of the regulations as they interpreted them.

And there’s the rub.

Separately, strictly following the “letter” or the “spirit” of the regulations can be problematic. Put them together in a contractual environment and the risk of conflict increases.

A company seeking to follow the letter of the regulations often approaches regulatory obligation as an externally imposed necessity. The company must somehow conform to the documentation requirements because to be cited as non compliant can harm their reputation, create greater regulatory oversight, interfere with contracts and revenue generation, or worse.

Such companies easily gravitate to a narrower interpretation of regulations with a checklist mentality of obligation and the belief that if they can address the checklist items, justify them, and conform to the checklist, then they’ll get a more cost effective path to compliance and achieve auditability. But such benefits are frequently limited because a check list mentality often means either achieving too little or too much in a compliance effort.

On the one hand, checklists can create inflexible approaches that generate costs. We’ve seen many companies using software for critical functions whose strict interpretation of 21 CFR Part 11 controls suggested a checklist of user and functional requirements that far and away exceeded their development budget. They would have achieved compliance by following the checklist, but at a cost that was unnecessary and without creating any real benefits. Once they adjusted their approach to accommodate the intent of Part 11 within the context of their current circumstances, they found a cost effective development solution that added value and achieved FDA compliance.

From another perspective, checklists can produce regulatory shortcomings that generate risk. Organizations that drive their quality culture with checklists tend to have great difficulty in extending good quality practices and oversight company-wide. We’ve seen many organizations with very superficially attractive SOPs but when their operations are examined closely the reach of those SOP’s do not extend with evidentiary assurances beyond what is normally reviewed during a superficial audit. For example, validation of software systems in support of a Sponsor’s project is often the subject of short cuts which can include missing requirements that identify the products’ intended use and informal or incomplete testing intended to replace formal validation. Such short cuts are easily hidden in thick binders of documentation where accountability for validation is difficult to establish without a trained eye. The consequence is the absence of clear accountability for data integrity and, therefore, a risk to the Sponsor’s data.

At the other end of the spectrum are companies whose quality compliance vision is driven by the spirit of the regulations. Typically we see this in Sponsors and their relationships with CROs. Sponsors believe that quality should somehow be imbued into the very fabric of an organization, a belief that can often manifest itself with a Sponsor expressing a quality vision that is made up by selecting for a particular set of tasks the most rigorous relevant regulations for guidance. For CROs, it becomes difficult to meet Sponsor expectations that leave the CRO confused or with the view that the Sponsor does not have clear expectations. As a result, the CRO too often assumes the role of defining for the Sponsor the expectations that the CRO will meet.

The root causes of the conflicts between Sponsors and CROs is primarily the lack of due diligence by the Sponsor to determine the “right fit” of the CRO and the unwillingness of the CRO to understand the expectations of the Sponsor. Sponsors should always thoroughly audit their vendors as part of their vendor selection process (not as justification for their vendor choice) and the Sponsor’s regulatory affairs / quality experts should have input on the vendor contract to ensure that their regulatory expectations are a point of contractual obligation. CROs should insist on fully vetting the Sponsor’s expectations before the engagement and be clear in advance what will be accomplished or where a compromise should be made during contract fulfillment. Failure in either regard can mean a costly change of scope down the road or unacceptable project risks.

Every life science company is different and every contractual relationship between life science companies creates opportunities for improvement. Having the right intentions does not by itself create auditable best practices. Generating auditability does not necessarily imply that a company is doing the right thing.

But the life sciences industry has a much better shot at fulfilling its public mission by integrating through cooperation both the Spirit as well as the Letter of the regulations.

Russ King is Managing Partner at MethodSense, Inc.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Are The NERC Requirements Strong Enough To Protect The Power Grid?

James Holler, Founder, Abidance Consulting

The NERC requirements might help the people at NERC and the regions get a better night’s sleep, but a sound action plan, including situational awareness, is the only true way to get there — and ensure greater cybersecurity for all.

With so much at stake, NERC is faced with a daunting challenge of locking down the nation’s cyber infrastructure as it pertains to the power grid. NERC has forced registered entities to establish programs for securing their Critical Assets and Critical Cyber Assets that includes dedicated management, oversight, accountability of corporate officers, processes for securing IT systems, and mechanisms for measuring progress.

Of course, just meeting NERC requirements doesn’t mean a registered entity is secure. NERC should recognize its shortcomings and pass a measure that will, among other things, strengthen the role of an industry recognized leader like the National Institute of Standards and Technology in shaping cybersecurity requirements.

So, why is cybersecurity such a challenge? That’s a loaded question because today’s information infrastructure is a quandary. Some of the issues are:

Advanced Persistent Threat

Cyber criminals have become more sophisticated, outpacing defensive measures. Hackers constantly exploit weaknesses in popular products and create new techniques using viruses, rogue antivirus software, keystroke loggers, botnets, and other tools, for immediate targets or time-triggered actions.

New Dynamics

Registered entities have completely changed the way they communicate, interact and accomplish their missions. They’re sharing information in new, amazing and sometimes scary ways—from portals (regional scale for the most part) to social networking websites like LinkedIn. They’re even bringing trusted third parties into the fold. And their flexible IT model is establishing technology options that could present more risks, such as mobility and cloud computing.

Shared Risk

All of this is extending NERC’s reach into the critical infrastructure. Yet, 95% of that infrastructure is in the hands of the private sector. Risk to that infrastructure, information assets and private data is rampant with potentially deep and catastrophic consequences. The fact is, registered entities are giving more and more access to data and applications, a concept that runs counter to most security type of thinking. Traditional network security that relies on reactive measures simply isn’t enough.

Pay Closer Attention To Applications

Whether off-the-shelf or home-grown, most applications are not engineered with security in mind, so you need to ensure trusted development processes to maintain their integrity. Today, that means adhering to requirements set-forth by the NERC requirements. Trusted delivery is also critical — especially with innovations like cloud computing. Protecting the perimeter around applications is not a sufficient defense and you must extend security to the application layer. In every case, you need to be able to measure an application’s ability to process and handle sensitive information throughout its deployment lifecycle.

James Holler is founder of Abidance Consulting.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

NERC Raises Stakes with ‘New Direction’ for CIP Standards

Michael Causey, Editor & Publisher, eDataIntegrityReport.com

Complying with regulatory requirements might just have gotten a lot tougher for those involved in producing and protecting the nation’s power supply.

At its meeting on April 13–16, 2010, NERC decided it will be retiring the existing CIP standards and replace them with new ones starting at CIP-010. Since this announcement, NERC has tabled CIP-010 and CIP-011 until next year and are now focusing on CIP-002-4.

That sounds innocent enough, right?

Not so fast. “It’s a huge and significant change,” warns AssurX expert Paul Fricke. He’ll be leading a summit on NERC and power grid compliance issues later this month in Chicago. A highlight of that seminar will be a presentation by big power firm PG&E. Company exec Thomas Bilbo will explain how PG&E is developing an enterprise compliance management system using CATSWeb as the backbone. Areas covered include: internal and external compliance requirements/commitments, the connections with business processes, and the controls/methods/evidence to ensure compliance.

“We want feedback from industry about how these changes will impact them, and how we can help them to better handle these changes,” Paul says.

NERC’s latest moves mean, among other things, that regulated entities will have to track their self-certification tasks much more effectively.

CIP-010-1 establishes the foundation for a shift from identification of system elements to a focus upon the systems.

The draft standard requires BES Cyber Systems to be indentified and categorized in terms of impact (High, Medium, and Low) as well as identifying the systems essential functions. The functions and categorizations are outlined in the draft CIP-010-1 Reliability Standard.

CIP-011-1 establishes an array of  baseline cyber security requirements, which must be applied to protect the BES Cyber Systems identified and categorized in CIP 010-1 according their impact category.

So instead of a relatively vague set of rules, we’re looking at far more specific requirements in table format. “This will set the requirements in terms of low impact, medium and high,” Paul notes. For example, high impact system requirements, the new regulations might require action to be taken in a specific amount of time, say an hour or four hours, where in the past it may have been days or not even specified, Paul adds.

The comment period for this ended in June, and Paul says industry did weigh in with comments, but he also worries that industry may underestimate how much time and other resources this new bar for compliance may require.

“CIP-002-4  gets closer to where CIP-010-1 is going,” Paul notes. It seems to be a smaller step to clearly require classification of Critical Assets, but does not leap to BES System identification and classification…yet, he adds.

ASSURX NERC RESOURCE CENTER

AssurX NERC Compliance Information

Consultant James Holler’s regular NERC-related blog

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Part II: Protect Your Data and Your Company From an Internal or External “Hack-Attack”

James Holler, Founder, Abidance Consulting

In Part 1 of this series, we touched on some ways to make it so difficult to pull off a hack-attack, that the perpetrator will most likely want to go somewhere else and try their attack.

In this section, we’re going to address testing, maintaining and other important items that deserve your attention.

Testing

Once you have fixed all of the issues, you need to test everything to make sure it works the way it is supposed to. You must first create benchmarks in which you are testing against. Just to run a test for the sake of running a test is futile. Once the benchmark(s) have been set, you are ready to test:

  • Run port scans to ensure only required ports and services are open and/or running
  • Firewalls detect intrusions
  • Switches and routers have only active administrator accounts
  • Passwords adhere to compliance requirements etc

Be sure to document your test procedure(s) step-by-step as well as the test results. Note if the outcome of the test was expected or not. If there is anything that fails during your testing, you need to fix those issues and retest. Don’t skimp on testing…hackers are not forgiving and just like in dodge ball, there are no “do-overs”.

Maintaining

Once you have tested everything and are assured that your organization is where they need to be, you now need to create and maintain a testing program. Don’t try creating a maintenance program prior to everything being tested, as you will surely be making changes to the maintenance program, making are previous efforts null. Your maintenance program needs to have firm dates / times set for scheduled maintenance. You need to have multiple maintenance programs set up such as:

  • Patch management
  • Password management
  • Network account management
  • System management
  • Applications management
  • Operating system management
  • Security administration etc

By setting up multiple maintenance programs you are able to create “silo’s” for each area and assign personnel who are responsible for each of these areas. This allows for a better view should there be a failure in any of these areas…and makes it easier to see where the failure occurred and to fix the area faster.

Worth Considering

There are a few tricks that you can implement on your network that will make a hacker think twice about trying anything. The more difficult you make it for the hacker to attack, the more likely it is that they will go somewhere else to attack. As someone who has spent the better part of the past quarter of a century protecting companies against attackers, I have listed a few neat tricks you can implement:

Honey Pots

A honey pot is a trap set to detect, deflect, or in some manner counteract attempts at unauthorized use of information systems. Generally it consists of a computer, data, or a network site that appears to be part of a network, but is actually isolated, (un)protected, and monitored, and which seems to contain information or a resource of value to attackers. These honey pots can be used to track and in some cases trap and report a hacker.

Trace Routing

Having the attacker’s IP is all well and good, but what can you do with it? The answer is, a lot more! It’s not enough to have the address, you also need to know where the attacker’s connections are coming from. You may have used automated trace routing tools before, but do you know how they work?

Go back to MSDOS and type tracert *type IP address/hostname here*

Now, what happens is, the Trace route will show you all the computers in between you and the target machine, including blockages, firewalls etc. More often than not, the hostname address listed before the final one will belong to the hacker’s ISP company. It’ll either say who the ISP is somewhere in there, or else you run a second trace on the new IP/hostname address to see who the ISP Company in question is.

Reverse DNS Query

This is probably the most effective way of running a trace on somebody. If ever you’re in a chat room and you see someone saying that they’ve “hacked into a satellite orbiting the Earth, and are taking pictures of your house right now”, ignore them because that’s just bad movie nonsense. THIS method is the way to go, with regard to finding out what country (even maybe what state/city etc.) someone resides, although it’s actually almost impossible to find an EXACT geographical location without actually breaking into your ISP’s head office and running off with the safe.

To run an rDNS query, simply go back to MS-DOS and type netstat and hit return. Any active connections will resolve to hostnames rather than a numerical format.

DNS stands for Domain Name Server. These are machines connected to the Internet whose job it is to keep track of the IP Addresses and Domain Names of other machines. When called upon, they take the ASCII Domain Name and convert it to the relevant numeric IP Address. A DNS search translates a hostname into an IP address….which is why we can enter “www.hotmail.com” and get the website to come up, instead of having to actually remember Hotmail’s IP address and enter that instead.

Well, reverse DNS, of course, translates the IP address into a hostname (i.e., in letters and words instead of numbers, because sometimes the hacker will employ various methods to stop netstat from picking up a correct hostname).

While we’ve given you a very high level look at what needs to be done to better protect yourself from a hack attack, we believe it represents the best place to start in understanding what you need to do.

James Holler is founder of Abidance Consulting.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Part I: Protect Your Data and Your Company From an Internal or External “Hack-Attack”

James Holler, Founder, Abidance Consulting

Part 1 of a 2-part series

First, let me start with the bad news: There is no absolute way to prevent an internal or external hack-attack. With that said, there are some things that you can do that will make it so difficult to pull off a hack-attack, that the perpetrator will most likely want to go somewhere else and try their attack.

Now, there is an old saying, “cleanliness is next to Godliness.” I am sure you have all heard that line at some time in your life. This saying holds true in the security world. If your network is in total shambles (DAT files not updated, Service Packs are so far behind your need an abacus to determine how many versions behind you are, etc.) and your Intrusion Detection System (IDS) is monitored by humans only during business hours, then you have a “dirty” network that needs to either be cleaned, or as my mom used to tell me…let’s just burn your room and start over, it will be easier that way. If your network/server room looks as if a spaghetti factory has blown up, get it cleaned up by rewiring it using tags on each line so you know where each of the cables is assigned.

The first thing you need to understand in preparing to get your network in top form is to not only determine what is wrong with it, but to also be open to criticism from experts. Put away the ego (one of the top reasons why networks are in shambles to begin with) so that you can listen and learn from your internal experts or external consultants – you hired them, now listen to them.

In Part 1, we’ll look at network discovery issues, vulnerability assessments, and discuss ways to fix some of these challenges.

Network Discovery

Before you can determine what’s wrong with your network, you must first know what your network looks like. You will want to conduct a thorough network discovery since you are going to need to know not only what devices are on your network, but also where they are. Please don’t think that you are going to run a piece of software that will show you everything. If you have a wireless or dial-up modem hanging off of your network and the power button is off, you may never discover it. You may need to do a physical inspection of your entire facility…look up in the ceiling…those pesky tiles can support the weight of a modem and even an old sandwich from 4 years ago. I personally use an iPaq handheld device that is capable of “sniffing” out these modems, even when they are turned off. Now that you have a true and correct picture of your network, you will need to conduct a vulnerability assessment to determine what areas are weak and are in need of attention.

Vulnerability Assessment

To ensure that there are no “cover-ups” by your staff, it is recommended that you have an outside consulting firm come in and conduct the assessment for you. Depending on the size of your organization, the fee’s for this could be $15k to $30k or more. The final report to be delivered should be comprehensive in nature. Be sure to ask for sample reports prior to awarding a contract or project to anyone. There are areas that must be looked at closely. Make sure whoever you assign the project to gives you a list of the services they are going to run. My only word of caution here is that you do not allow a penetration attack be made against your Primary Domain Controller (PDC). Once the assessment is completed, make sure that you not only address the issues, but fix the issues.

Fixing The Issues

When you do get the final report, there are going to be a lot of errors that need to be fixed. Don’t worry; the “bark” of the report is much worse than the “bite”. Depending on how bad your network was when the assessment was conducted, you may have a few pages of issues to as much as a thousand pages of issues – one assessment we did a few years back yielded almost 7,000 pages (a government agency…need I say more). When you are reading your final report, one of the first questions you need to ask yourself is, “Where do I begin”? Not to worry, your security staff/consultants should prioritize what needs to be done and at what point in the project does it need to be done. The point at which a certain task is completed is very important since everything has a logical order of semblance to it…you wouldn’t put the seats in a car before you laid down the carpet. Your staff and/or consultants should know this and be able to build out a project plan with a scope of work, keeping you (the stakeholder) in the loop at all times. Never be afraid to ask questions or challenge something if you feel it isn’t the right thing to do or you don’t understand why something is or isn’t being done.

To save time and money, you have to look at all of the different compliance issues you have to deal with (NERC, EPA, OSHA etc) and cross-walk your efforts to all of these compliance requirements. Doing this will ultimately save yourself time and money by not overlapping efforts.

Next time, we’ll look at testing, maintaining, and some other important issues that merit your attention.

James Holler is founder of Abidance Consulting.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare

Hackers Up the Ante in Attack on Electronic Data in Power Plants and Other Facilities

James Holler, Founder, Abidance Consulting

According to the Wall Street Journal (WSJ), computer hackers have designed a virus that targets the industrial control systems, to include power plants, built by German engineering giant Siemens AG. The virus apparently activates a kind of malicious software that analysts say represents a growing corporate-espionage threat. This type of threat has been talked about for years — and it is now a reality.

The virus, Stuxnet, is spread by USB devices plugged into the physically unsecured USB ports on the machine(s) hosting the SCADA systems used by power plants and other types of facilities. The virus is programmed to steal data from computer systems that are used to monitor power plants built for anything from manufacturing to power generation to water treatment.

Researchers analyzing the virus say that they are now seeing several thousand infection attempts daily, though the virus is only activated if it lands on a computer running the Siemens systems software. Analysts warn that the attack on the Siemens’s systems marks an escalation in hackers’ efforts to use viruses for industrial espionage or sabotage purposes. This attack will surely make the NERC CIP regulations become even tighter more quickly than before this story broke.

Smaller, more isolated virus attacks have been attempted before on SCADA systems, but this is the first such infection where a virus is searching specifically for SCADA systems to attack on such a large-scale basis. The worry among security analysts should be that such viruses will, at some point, be used by criminal organizations or even terror groups to sabotage power plants.

The Stuxnet virus specifically exploits an unpatched vulnerability in the Microsoft Windows operating system, allowing it to spread through all USB devices. Once the virus has infected the Siemens system, it uses default passwords that are hard-coded into the Siemens software to upload false control-system data to a remote server. In an advisory that Siemens posted on its website, the company said Microsoft was working on a patch to fix the vulnerability at the USB interface. In its own website advisory, Microsoft has provided a workaround fix to offer some additional protection until a patch, or update, is ready.

Siemens said it expects to approve the updated virus scanners this week and also plans to provide customers with a diagnostic tool to check if their systems have been infected. In the meantime, the company’s website advisory urges customers not to use any USB storage sticks.

Siemens, Microsoft and other security analysts haven’t determined where the virus originated. Many of the infection attempts have originated from India, Indonesia and Iran. The virus likely was created in Asia, given the pattern of attacks and technology used.

James Holler is founder of Abidance Consulting.

TwitterFacebookGoogle+LinkedInEmailPrintFriendlyShare