On the heels of yesterday’s post regarding PCSF, I am also pleased to announce that Dr. Nate Kube has been selected to speak at the 1st Annual Cyber Security Conference to be held in Calgary, AB from September 8-9, 2008.  As strong advocates for industrial cyber security and critical infrastructure protection, we are pleased to extend our message to our home country and hope this conference will be the first of many to come into the future.

Topic: The Next Generation of Industrial Cyber Security Risk Intelligence - Implications for Industrial Control Systems and Critical Infrastructure Protection

Presenter: Dr. Nate Kube, CTO
Time: Monday, September 8th @ 10:10 am to 11:10 am

About the 1st Annual Cyber Security Conference:
Focusing on Cyber Security and Critical Infrastructure Protection for Energy and Communications, this conference will look at understanding the current threats facing the industry, and will explore the myriad of solutions available. Delegates will enjoy fantastic networking opportunities and hear internationally acclaimed subject matter experts. The private sector will also be showcasing their newest innovations and cutting edge technologies in cyber security, through the conference exhibition and interactive management and technical track sessions.

Confirmed Speakers Include:

• Dr. Stephen Flynn, Homeland Security Expert, former US Coast Guard Commander and author of “The Edge of Disaster”
• Dr. Nate Kube, Co-Founder and CTO, Wurldtech Security Technologies
• Rob Anderson, MLA, Airdrie-Chestermere, Government of Alberta
• Patrick Gray, Senior Security Strategist, Cisco and 20 year FBI veteran
• Scott Montgomery, Vice President, Product Management, Secure Computing
• Brian Geffert, Principal, AERS, Deloitte & Touche, Washington, DC LLP, CISSP, ISSMP, CISM, MBA
• David Ruhlen, MBA, Consultant, Cyber-Security Solutions Corp
• Dr. Rei Safavi-Naini, PhD, iCORE chair, Department of Computer Science, University of Calgary
• Venkat Pothamsetty, Industrial Security Architect, Cisco
• Brian Phillips, Director, Bell Canada
• Barry Kokotailo, Systems Security Specialist, CSA/CSNA/CISSP/CEH/EnCE
• Michael Legary, Founder, Seccuris Inc. CSA, CISSP, CISM, CISA, CCSA, GCIH
• Mauricio Sanchez, Chief Network Security Architect, ProCurve Networking by HP

Conference Topics Include:

• The Next Generation of Industrial Cyber Security Risk Intelligence - Implications for Industrial Control Systems and Critical Infrastructure Protection
• Anti-Surveillance or How Not To Get Caught
• Secrets of Network Security
• Compliance with NERC - Critical Infrastructure Protection
• An Integrated Communications System Supporting Energy
• Wringing Business Value from Cyber-security Standards
• A Distributed Approach to Intrusion Detection in Wireless Sensor Networks
• CFATS: An Emerging Regulatory Challenge for Cyber Security
• Enterprise and Industrial Control Network Integration: Security and Architectural Considerations
• Cyber Criminals and their Latest Tactics

For full conference information, agenda and registration, please visit the web site at: http://www.rebootconference.com/security2008

�

Building on last year’s PCSF event in Atlanta, GA where we unveiled the Achilles Certification Program, we are set for another introduction at this year’s event in La Jolla, CA (August 26-28, 2008). Dr. Nate Kube will present AchillesINSIDE, one of this year’s most anticipated solutions from Wurldtech Labs.  Should be another fantastic event!

Topic: AchillesINSIDE – Intelligent Cyber Security and Risk Management for Industrial Environments

Presenter: Dr. Nate Kube, CTO, Wurldtech Security Technologies, Inc.

Time: Wednesday, August 27th

About the PCSF 2008 Annual Meeting:

End-user involvement in collaborating towards advances in control system cyber security policy, practices, standards, tools, resources and services is growing steadily. More organizations are discovering the benefits of participating in a common community where solution seekers and solution providers can exchange knowledge, learn from each other, build successful cyber security programs, and address the high priority, immediate concerns both common and unique to each respective environment. The 2008 Annual Meeting will provide solution seekers and solution providers the opportunity to come together and address these issues.

To learn more, visit: https://www.pcsforum.org/events/2008/

�

As some may have previously noted, I was able to participate in the Automation Federation’s first annual fly-in to Washington DC in May of 2008. The meeting was a sound success, with a number of follow-up’s scheduled as a result of our meetings. The first of these follow-up’s came last week as a sub-team comprised of Ernic Rakacszky from Invensys, Eric Cosman from Dow, Johan Nye from Exxon Mobile, Michael Marlowe from the Automation Federation, and myself.

During this visit, we specifically came back to meet with staffers from several senator’s that are looking into the issues of cyber security for SCADA and process control systems, as well as members from the House Homeland Security Committee. The main topics of discussion were around:

• Why industrial cyber security has been such a challenging issue to address
• What industry, specifically groups like ISA-99, Automation Federation, ASCI, PCSF, NERC, and others have been doing to address these challenges
• Where has the US government been effective in encouraging progress
• What more can government do to support and drive such efforts

There were some very interesting messages that came out. There definitely seems to be growing frustration that industry is not moving along fast enough to address what the government sees as a looming threat. Of course the dilemma is that threat information that the government and defense agencies sees is typically very sensitive, classified, and doesn’t make it far down into the hands of industry. The government has done some things to help the process, including providing clearance to select people in various companies to try and increase information sharing. The problem here is that if there is a big wall between industry and government, disseminating information to only a select few people, and placing heavy restrictions on what they do with this information, only serves to knock out a few bricks of that wall, or at best move it a ways from center.

With GAO reports such as the one concerning TVA recently, and more coming, is it clear the the US government is taking the issue of SCADA and process control security seriously, and starting to hold operators of infrastructure accountable. Another example includes the FERC (the regulatory arm of NERC guidance), which is lobbying for increased authority and many in government are supporting this action as well to help drive effective security policies. With over 70% of the nation’s critical infrastructure held in private industries, it is clear to all that in order for real improvement to occur, the government is going to have to get involved and increase sharing and dissemination.

This visit is sure to generate more traction, and meetings such as these have already been very instrumental in knocking down barriers, such as the fact that I now sit on the NERC SAR team for the next revision of the CIP documents as one of the chair’s of ISA-99, and inclusion of such fine individuals as Keith Stouffer from NIST, to help increase industry collaboration and improve information sharing. A CLEAR message from the government is that we asked for more involvement, and now we are getting it, so don’t drop the ball.

I left DC very encouraged by the process. No, it isn’t perfect, yes it is slow, but two things are VERY clear:

1. The government is indeed here to help, and they are paying very close attention
2. Despite being an election year, there is considerable pressure and support from both candidates that this will be a hot button item a the executive branch as well as legislative branches from now on

For the rest of us, it is also clear: This issue is not going away, and the luxury of doing nothing, for those that made that choice, is no longer an option.

To read up on my initial visit and/or learn more about the Automation Federation, please see my part 1 of my posts here: http://www.wurldtech.com/blog/?p=74.

Joe Weiss has released the tentative agenda for the upcoming 2008 Applied Control Systems - Control Systems Cyber Security Conference set for August 4-7, 2008 in Chicago, IL. 

We are excited to announce Dr. Nate Kube, Wurldtech’s Co-Founder and CTO, is slated to present, “Considerations for Security of Integrated Safety Instrumented Systems (SIS): A live Demonstration of a SIS Security Compromise” on August 6th at 2:00pm.  More information on this timely and extremely significant presentation will be coming shortly.

With a full line up of speakers and topics, this year’s ACS Conference promises to be one of the most informative events of the year for the industrial cyber security community.  

Conference Overview

• Case studies of control system LANs
• Discussions of control system forensics
• Case studies of control system security mitigation technologies and good industry practices
• Demonstration of hacking control systems and discussions of possible solutions
• Case histories of control system cyber events
• Discussions of control system regulations within different industries
• Control system security standards poster session
• Interdependency session

Benefits of Attending the Conference

• Learn about the most recent developments in control system cyber security
• Obtain a better understanding of the differences between control systems and IT
• Understand the similarities between control systems in different industries
• Bridge the divide between Operations and IT in securing control systems
• Meet with your peers from different industries, suppliers, government, and academia

For full conference details and registration information, please visit the conference site at: http://realtimeacs.com/?page_id=18.

�

While this story is getting a bit dated, the timing for my article now is intentional. As you may have seen recently, CORE Security released a cyber vulnerability notification for a problem found by one of it’s analysts in a CITECT product, http://www.coresecurity.com/?action=item&id=2186.

This leads us to question whether or not vulnerability disclosure is the right thing to do or not for the SCADA and process control industry. Of course this question comes up time and again for us here at Wurldtech as well. Hardly a day goes by that a vendor or asset owner asks us if we are going to release the vulnerabilities we find in industrial control systems, and we find a lot. Vendors are concerned we will publicly release the data without giving them a chance to review it. Asset owners are split, some want us to release, some do not. Those that do want us to publish as widely as possible so that they can get the vendors to deal with the issues. Those that do not are concerned about protecting their own facilities.

One thing is for sure…. perhaps two things:
1- Releasing or not releasing, no matter what you do, a massive amount of people will be mad. It seems to me that NOT releasing probably has a lower anger threshold than releasing, and is also a more ethical thing to do. More on that later where I will expand this point
2- No matter what we do (or not do), SOMEONE will release vulnerabilities. For those that don’t know the security business, many “white-hat” or “gray hat” firms actually purchase vulnerabilities from crackers that wish to remain anonymous. Sometimes these crackers have altruistic motives (aka whistle blowers), and sometimes they just want to get paid. Either way, vulnerabilities have come out and will continue to come out.

Did CORE do the right thing? I am sure we can debate this for a long time. They are a respectable organization and they do some great work, and they are free to do what they think is right. I have no idea the extent to which they may have worked with the vendor ahead of time. Not my place, nor any of ours, to decide what is right and wrong.

Here is the problem: Vulnerability disclosure is the norm in the IT world, not the exception. If the good guys don’t do it first, then the bad guys will. I would much rather the good guys be the release agent, AFTER they have worked with the vendor and given them a chance to respond.

Before someone jumps to the conclusion that I am saying we should release vulnerabilities, and wondering when Wurldtech will, don’t jump the gun. There are a few factors here to consider:

1- Industrial cyber security is still an evolving discipline and lots of lessons to be learned
2- Fixing vulnerabilities is not so easy, patching just isn’t the normal mode of operation (yes, I know many companies have found a way to do it, that is not this discussion at this time).
3- Hackers/Crackers are not, for the most part, distributing vulnerabilities and security hacks for control devices, yet. That is changing, and will change, but why should we rush the process?
4- Vendors and asset owners still are coming to grips with how to deal with these issues
5- Solution providers still have a ways to go to offering solid, comprehensive cyber risk mitigation strategies.

All of this is coming, and it is an exciting time for sure. We are definitely carving new snow and defining ways to address problems that were previously not even imaginable, let along achievable.

Is releasing the right thing to do? I will not try to decide, nor judge, if these companies have made the right choice by disclosing or not. What I CAN say is that it is not the mode of operation for Wurldtech. We think it is more important at this time to increase the body of knowledge about security failure modes, build resilience profiles for broad categories of devices, and work with vendors and asset owners to define intrinsic security fixes, compensating controls, better network management, and process optimizing solutions that target the things that operators and owners really care about: keeping operations running and efficient, period.

The Achilles Delphi program is a great example of this leadership. We are already testing and actively building this knowledge, and we are working to put together actionable information in the hands of those that need it. We are not releasing vulnerabilities as part of this effort, but rather mitigation solutions and things that vendors, solution providers, and asset owners can actually run with.

Will we someday release vulnerabilities? It will depend on market demand, and the general level of capability in the market. We have been very critical of those in the past that have release vulnerabilities, largely for the reasons above. One can rest assured, however, if we every DO decide to release, it will be done to the highest professional and ethical standards, and it will only be done once vendors have had an opportunity to work out the issue, and we know a mitigating solution to the problem. It certainly will not be for “the glory of the 0-day.”

As I have said now many times… we are not in the business of finding problems just so we can get paid to fix them. Wurldtech’s mission and focus is to improve the reliability, resilience, and security of industrial devices and SCADA systems, and raising the bar for the industry to drive secure, efficient, and benefit driven solutions to our customers, period.

As some of you may have been watching on the SCADASEC email listserv recently, there has been a bit of an uprising… again. Pondering this in a semi satirical state last night (after about the 20th email sent and received on the issue), I started wondering why this happens so often. It finally hit me… we have two very distinct camps on polar opposite ends of the spectrum. Let’s call them pneumatic pumpheads and bit-twiddlers. Now, before any feathers are ruffled, keep in mind that this post is equal-opportunity - everyone is going to be given an equal ration of grief…

For the purposes of this post, its VERY important to remember that everyone has a lens through which they view the world. Even using the same terms and language, people can see different messages because of the lens that they use, it’s unavoidable. So, while we are reading this post, let’s get our prescriptions checked and try to think in as much of an unbiased way as we can.

Pneumatic pumpheads represent the “classic” versions of engineering. They are mechanical, electrical, chemical, civil, logistical, and just about any other version of engineer out there. They often represent folks that have lots of experience and knowledge about any given process, but they also often are locked in the ways that they have always thought. If you have every been to any type of plant, you recognize the person immediately. They are the ones that can crunch calculus in their heads, work a calculator like no one’s business, but they are also the ones that look down their nose at computers and constantly complain that the computer, “just doesn’t work.” Their knowledge of engineering and process is often first rate and of vital importance, but many just don’t want to know about computers. They are often very precise, very literal, and very utilitarian when it comes to solving very complex problems. But, they are much happier to solve the problem with a wrench, blowtorch, and good ‘ol fashioned sweat equity.

Now, bit-twiddlers. These are the folks that think in 1’s and 0’s, they see the world through computer logic, state machines, and that nothing is “absolute” quite often. These are the folks that bring us things like linear algebraic solvers to optimize a blending process, monitoring and control solutions that allow one person to support eight plants, and would rather sit at their desk than don fire retardant clothing, hair nets, steel toed boots, and venture into the plant. They often arrogantly view engineering as a “subset” of computer science, and don’t understand why distributed control can be a bad thing (tell an operator of a turbine or a boiler that you want to make changes from three states away, and you are likely to learn a few new words from him or her). To these folks, they can not understand uptime, availability, etc. They would rather sit at a keyboard and direct the plant. They are into problem solving, but in a more abstract manner. Problems to them require elegant solutions, and they are more likely to write a logic tree, decision support matrix, or some kind of statistical solver to deal with natural variability in a process. There are no absolutes to them, only optimization. Theirs is a discipline where elegance often wins out over practicality, and critical issues such as safety. I’m reminded of an auditor a few years back that told me (after they shut down the plant and created several major issues from a network scan) that their way was much faster and they would keep doing it the same way from now on. She just refused to believe that these were possible safety issues… her lens told her that there was no way that a network scan could ever hurt someone.

Arrogance abounds on both side of course, and these are definite polar opposites. Many people sit somewhere in the middle. Myself, I’m an IT person (software developer and systems admin) that happened to land in engineering and industry. So, I probably fall somewhere in the middle. The modern plant is developing more of these middle ground folks, it is where we have to go. Some schools are offering courses at the bachelors and masters level now in “mechatronics” which fuses engineering disciplines with IT and computer logic disciplines. This IS the plant of the future.

So, its not an “either / or” but rather a “both / and.” We will not solve the challenges of today by thinking like the engineers of yesterday, and we can not arrogantly assume that the cutting edge of computer systems and technologies can solve all problems. Students coming out of school today and folks that are coming up to replace the aging workforce have more computer skills than ever before. Economics and the need to compete in the global economy is driving the need for more efficiencies, and is casting “one-trick ponies” off to the side. If you only understand one discipline, don’t be surprised when you job moves overseas and you are left in the easy chair complaining about it being unfair. The world is a different place and we all must be ready at any moment to reinvent, diversify, and lead.

In the not too distant past, cutting edge western medicine explained illnesses in terms of humours.  If you had a cold, you had too much phlegm, so you would balance your humours by increasing your yellow bile, which was antagonistic to phlegm.  Apparently this involved sitting in bed and drinking lots of wine.

Now, as comfortable as this remedy sounds, it has a drawback: it doesn’t work.  The idea of humours has some correlation with reality, since it was based on observation, but it is oversimplified.  Now we know that the outward symptoms of colds are our body’s attempt to remove an invading virus.  Our knowledge is still far from perfect, but we know why there’s all the mucus and sneezing.

The important difference is that we now view the human body as an extremely complex system, with failure modes and compensation strategies all built in.

Our current view of network security and reliability is very much like the Hippocratic view of medicine.  If you have hackers, you have too many vulnerabilities, so to counter them you get patches and firewall rules.  Apparently this involves buying more software.

Now, as comfortable as this remedy sounds, it does have one drawback: it doesn’t work.  Just like with the body before it, we are largely failing to view networks as interconnected systems of purposeful parts.  Because of this, our ability to understand potential failure modes, our ability to anticipate, plan for, and prevent them, is compromised.

This is especially significant in the realm of SCADA systems and process control, because there are fewer allowable failure modes and the complexity of the network is higher.  In IT, if a server goes down, people are inconvenienced, but they have intelligence and agency that allows them to compensate and still get things done, albeit at a lower rate.  On SCADA and process control networks, the users are PLCs, sensors, and microcontrollers, and they can work without the network no more than you could pick up a cup of coffee without nerves between your eyes, brain and muscles.

In traditional control environments, there is an understanding of the failure modes of the components of the system and the way these failures impact the rest of the system, and there are entropic fault rates that have allowed us to make accurate estimates of system reliability.  But now, control has moved to a networked environment, and this has created new complexities that aren’t fully understood, and has introduced new, non-entropic fault types that we don’t know how to model.

Obviously, we need to learn how these new fault types affect system reliability, and we need to understand how they are caused and how to mitigate the risks.  And of course, this has to be done while accounting for the stringent availability requirements that differentiate ICS from IT.

The key to this is knowledge.  If we know what produces data, where it travels and what consumes it, we can deepen our understanding of how the process will be disrupted if any part of it fails.  If we know how these components behave and where their weaknesses are, we can deepen our understanding of which disruptions are most likely and choose our compensation techniques to maximize their effect on reliability and minimize their scope and cost.

Asset management and change management are important parts of this equation, because effective judgement needs accurate knowledge.  For the same reason, knowing about device vulnerabilities is important, as is understanding what part of the process the devices drive, and how they work together.  With all of this knowledge, we could conceivably have the level of certainty in networked environments as we do in normal entropic-fault environments, but the sheer volume of information involved means we’re just as likely to choke on it and fail to identify cyber risks, which would leave us right where we are now.

At Wurldtech, we are working to automate the analysis of this information.  Resilience profiles for devices are part of the equation, allowing us to gather everything we know about a device into a concise summary, but we are also extending this by developing techniques for threat modeling network-based processes which will further condense this information and allow us to predict the nature and severity of failures, analytically determine the key points of risk to a network, and find the most cost-effective strategies to deal with them.

- Reid Orsten

Design for test - a fundamental tenet in the development of quality software. [“Quality software” satisfies its requirements and ONLY its requirements, and runs in acceptable time and space.] Given this basic tenet one would imagine the Developer works closely with his test counterpart, collectively specifying and designing efficient tests to assure an artifact’s quality. Of course, one would also expect the converse, the Tester and his development counterpart working in concert to define which test result data is most useful to quality improvement and process evolution.

Sadly this far from the case and I didn’t give it much thought  until I attempted to “strengthen” the developer-tester cohesion in my own company. 

We talk about how improved PCN security is impeded by cultural differences b/w operations and IT folks, well, funny enough, the same can be said about software quality; its improvement is impeded by cultural differences between testers and developers.

Consider the following:

• Developers write code for requirements that are satisfiable and in the case when they’re not, the requirements are “adjusted” accordingly.
• Testers write code for requirements which, by their very definition (to prove the quality of an artifact), are not satisfiable and are excited by such.
• Developers expect their questions have answers, testers accept theirs do not.
• Developers, in general, work, live, and play in the complexity space of P - problems solvable in polynomial time and space.
• Testers on the other hand, live, work and play in NP – problems only solvable in exponential time and space (effectively computationally intractable, i.e. problems for which there are no feasible solutions).  Approximations, probability based randomized algorithms, best guess algorithms, are common place.

These may seem like minor differences, P, NP, etc. But they are a fundamental indication of an overall mindset that, generally, mixes like water and oil: the best you can expect is a weak emulsification.

The Developers and Testers who embody their profession (yes, the dedicated zealots such as I) are diametrically opposed ergo they yearn to work further apart, ergo neither job is performed optimally, hence design for test is handled extremely poorly in practice . And that’s reason #4,125 commercial software is exploitable.

Bryan Singer, VP of Security Services for Wurldtech, is heading to Washington DC and Capitol Hill next week, 20-22 May, as part of a delegation from ISA called “The Automation Federation.” The purpose of this group includes several facets, but Mr. Singer is on one of two teams selected to represent the needs of cyber security in industrial settings and critical infrastructure. The event includes meeting a number of US Senators and Congressmen, as well as a number of other meetings and briefings on Capitol Hill and at the White House. This would not have been possible without the strong commitment from ISA and the hard work they have put into turning this vision into reality, and the meetings would not be possible without the gracious support of the members of this group and their companies.
Here is the Press Release

This is a very important event for industrial security and seeking greater recognition and support in addressing the challenges that face critical infrastructure and all industry. Mr. Singer is extremely honored to be able to participate in this important event and all of us at Wurldtech and across industry look forward to the results that the members of this federation are sure to achieve!

There’s been a lot of activity in the past 6 months in various blogs about the need for responsible public disclosure policies for members of the ICS security community.  While the IT community has developed accepted policies and procedures over the last decade, vulnerability disclosure is still recent in the ICS security community, and it is only starting to grapple (as the IT community first did) with the issues of disclosure.  Unfortunately, the differing natures of the critical infrastructure, SCADA and process control industries compared to the IT communities preclude adoption of their relatively mature disclosure mechanisms and policies, and we must develop our own.

But it’s not enough to develop and publish a disclosure policy.  It must also be effective, actionable, understandable, and meet the needs of the industrial automation community. And development of a good policy starts with addressing the W5 questions about disclosure.

Who do I disclose to?
Vulnerabilities need to be disclosed first to vendors, then to the industrial cyber security community, then to the asset owners and operators of critical infrastructure, and finally to the public.

Vendors must take first responsibility to come up with approved patches or workarounds, and to notify their customers where possible on what to do about it.  The industrial cyber security community needs to know early on in order to develop and deploy effective design strategies and security programs to mitigate their customers’ risk.  Asset owners who employ vulnerable devices in their operations need to be informed of the vulnerabilities to understand the effects on operational risk, and how to reduce that risk.  And only then, once the vulnerability has been characterized, patches produced, and strategies employed to mitigate the risk in critical infrastructure operations, should a disclosure be publicly disclosed by a coordinating center such as US-CERT or CERT/CC.

What information do I disclose?
Vendors require as much information as possible that will help them to reproduce the fault associated with the vulnerability, and diagnose the cause. The ICS security community needs to know the effect of the vulnerability, and how it is triggered, plus any mitigation strategies that are known.  Asset owners and operators need to know the effects of the vulnerability and how it impacts the reliability of their operations, and mitigation strategies to reduce or remove the risk associated with the vulnerability.

When should I disclose?
You should disclose the vulnerability as soon as discovered to the device vendor.  It also makes sense to disclose to members of the ICS security community very soon afterward, as it often takes considerable time to produce a patch or workaround, and the ICS security community is in the best position to develop and deploy interim mitigation strategies to quickly reduce the vulnerability’s impact on critical infrastructure operations.  Asset owners should be notified once effective mitigation strategies have been developed, whether interim or permanent. And only once the patches and mitigations have been fully propagated to the ICS community should the vulnerability be publicly disclosed through disclosure bodies such as US-CERT or CERT/CC.

Where should I disclose?
Disclosure should not take place in public forums, as there is little or no control over vulnerability information propagation and use. Instead, disclosure should take place through secure traceable channels of communication with identified authenticated individuals, using appropriate non-disclosure agreements in place restricting the uses as well as the sharing of sensitive information.

Why should I disclose?
It is the responsibility of the industrial control and critical infrastructure communities to maintain the trust of the public with respect to the reliability of operations.  Vulnerabilities affect all of us, and we need to share information that will allow us to reduce both individual and collective risk on the reliable operations of critical infrastructure. Keeping knowledge of a vulnerability a secret is both short sited and does a disservice to us all.

By disclosing vulnerabilities in a responsible manner to the industrial automation community, we ensure that the development and deployment of patches, workarounds, and other remedies take place in an effective manner to the benefit of all.

From Policy to Action
It’s still not sufficient to craft a policy and put it up on your website for all to see. To be truly effective, your vulnerability disclosure policy must become a core value of your organization, and every employee in the company must believe in timportance of adherence to its principles. Only then will it translate into the everyday activities of your business.

To view Wurldtech’s Vulnerability Disclosure Policy, please click here: http://wurldtech.com/legal/disclosure_policy.php

- Breen Liblong

�