Friday, March 30, 2018

Enterprise Architecture Framework - Non-Functional Attributes

Non-Functional Attributes (NFAs) always exist though their signficance and priority differs when considered with certain other functional or non-functional attribute. It’s particularly important to pay attention and consider them in the inital phase of the EA framework development, as these attributes may have direct or indirect impact on some of the functional attribute of the framework. Considering Non Functional attributes early in the lifecycle is important because NFAs tend to be cross-cutting, and because they tend to drive important aspects of your architecture, they do cause considerable impact on certain important aspects of your test strategy. For example, security requirements will drive the need to support security testing, performance requirements will drive the need for stress and load testing, and so on. These testing needs in turn may drive aspects of your test environments and your testing tool choices.


The Enterprise Architecture team will interact closely with all the other management processes in an organisation, especially the IT management processes. When all these processes work together effectively, an enterprise will be able to successfully manage strategic changes and drive business transformation effectively and efficiently. Often in organisations little thought has been given to the integration of the EA processes to the other management processes. Identifying and considering NFAs early on will certainly of help in proactively address such issues. Having a clear picture of the NFAs help the EAs in taking into account innovative alternatives or trade-off before presenting decision-ready options. 


NFAs play a vital role in defining certain atomic properties of each enterprise architecture framework. The challenge with NFAs is that it is difficult to trace and identify the same. It is also difficult to define metrics to measure its performance. Described below in this blog are the typical NFAs that need to be considered while developing the EA Framework:


  • Adaptability – Be it people, process or technology, Adaptability as an attribute has never been more needed in the enterprise workplace. With the change happening at a faster pace than ever before, Adaptability is becoming a key attribute of every resource, including the human resouces apart from the systems. The resources identified as part of the EA Framework should have the the ability to accept and acquire the changes that is coming along. This way, the longivity of the EA Framework can be furthered with fewer or least changes to the framework itself.
  • Compatibility – EA Framework will have many artificacts which are not only interfaced with the other internal artifacts, but also with the external actors. Making this work seamlessly requires that the interfaces shall be compatible with each other at all times. The EA Framework shall be developed considering this important aspect of compatibility in mind and any incremental changes should not lead to break the compatibility, so that functional performance of the same is not impacted. Considering the compatibility of the artificats in the initial phase of the development of the EA Framework will save considerable efforts than fixing it when a compatibility issue surface later in the lifecycle.
  • Cohesiveness – Cohesion is the uniqueness in purpose of the system elements. A certain amount of formality is essential in providing uniformity and forming a coherent aggregate. This is critical when the components of EA Framework are developed by people both from a centralized EA team and from projects and programs. Obviously, lower level architectures should conform to the upper level architectures and unnecessary duplication should be avoided. Cohesion has to be considered in developing components or models describing a certain target area from different viewpoints. Utilizing a formal EA framework in an appropriate way is critical in achieving uniformity and cohesion in EA products.
  • Conceptuality – The benefit of enterprise architecture (EA) management is directly coupled to the underlying conceptualization of the enterprise. This conceptualization should reflect the goals pursued by the EA management endeavor and focus on the areas of interest of the involved stakeholders. A conceptual model captures the essential concepts that are present or should be present in the specific artifiact or entity and thus makes the understanding or visualization of such entity easier and unambiguous.
  • Coupling – It describes the level of dependencies between modules and components of the system. Loosely coupled systems minimize the assumptions they make about one another while still providing a meaningful interchange. Conversely, Tightly coupled systems have restrictive effect on the variability and evolution of the connected components or systems. The level of coupling that is appropriate for the particular system component shall be ascertained and considered while developing the EA Framework.
  • Diversity – Diversity is the difference between the systems or components of the EA Framework in terms of technology, methodology, principles, process, environment, etc. Diversity shall be at the manageable level, so as to minimise the cost of maintaining expertise in and connectivity between multiple processing environments. The advantages of minimum diversity include: standard packaging of components; predictable implementation impact; predictable valuations and returns; redefined testing; and increased flexibility to accommodate future changes. 
  • Dependability – As system operations become more pervasive, the enterprise become more dependent on them. Dependable systems are characterized by a number of attributes including: reliability, availability, safety and security. For some attributes, there exist probability-based theoretic foundations, enabling the application of dependability analysis techniques.  To ensure that all stakeholders at different level get the same understanding, considering the level of dependability expected out of the systems and components becomes critical. This will also ensure that the systems and components are developed and implemented as expected. 
  • Extensibility – One of the capabilities of the enterprise architecture is to allow for various artifacts of prebuilt integrations to be extended without or with least efforts. Extensibility also ensures that such system or component extensions are protected during implementing changes or revisions later on.  It is essential to evaluate and consider the appropriate level of extensibility of each system or component that is part of the EA Framework in the initial phase. 
  • Flexibility – It is a quality attribute of business information systems that contributes to the prevention of aging. It may also be considered as the capability of the enterprise to connect people, process and information in way that allows enterprise to become more flexible and responsive to the dynamics of its ever changing environment, stakeholders and competitors. This requires simplification of underlying technology and related infrastructure and creation of a consolidated view of and access to, all available resources in the enterprise.  
  • Interoperability – It is the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations). Clearly, making systems interoperable can mean many things. The strongest drive for interoperability is technical interoperability—the technical problem of sharing information that already exists in different systems from different times and places by enabling sharing, or at least providing connected technical services. Therefore, it is imperative to develop the big picture of what data the enterprise needs to share, to receive as incoming data and to send to other systems. Both end points may reside within the enterprise, or some may reside in external enterprises..
  • Maintainability – Maintainability is defined as the ease with which a system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. A fast and continuously changing business environment demands flexible systems easy to modify and maintain. Maintainability is said to be affected by; the maturity of the human resources involved, the maturity of the process governing change management, the quality of the systems' supporting documentation, the systems' architectural quality and the quality of the enterprise ecosystem on which the system executes. Thus, identifying and appropriately documenting the expectations around this attribute will certainly help implementing a better EA Framework.
  • Portability – It is the ability of the system to run under a different environment without any disruptions. Portability depends on the symmetry of conformance of both applications and the platform to the architected API. That is, the platform must support the API as specified, and the application must use no more than the specified API. Documenting the level of portability expected early on would contribute considerably in designing and developing the systems in line with the target platforms or ecosystems.
  • Robustness – It is the ability of a system to recover elegantly after failure or restart. Clearly, robust and easily modifiable automation is fundamental to achieving an enterprise’s vision for the future. However, such benefits don’t come without their price. Hard work and management commitment, both from IT and from the highest levels of the business are needed to build the kind of integrated IT architecture plans that will make the difference between success and failure in today’s highly competitive business climate.  
  • Scalability – It is the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth. Scalability, as a property of systems, is generally difficult to define and in any particular case it is necessary to define the specific requirements for scalability on those dimensions that are deemed important. The concept of scalability is desirable in technology as well as business settings.
  • Security – With the ever evolving cyber threats both on the IT and as well as OT, security has become a very important NFA to be considered in the development of EA Framework. Considering its significance, the Security requirements ideally should be intertwined with EA Framework. Security must be designed into data elements from the beginning; it cannot be added later. Systems, data, and technologies must be protected from unauthorized access and manipulation. Headquarters information must be safeguarded against inadvertent or unauthorized alteration, sabotage, disaster, or disclosure.
Most of the attributes mentioned above are easily reckoned as Non Functional Requirements with respect to a Software System. Though Enterprise Architecture by itself may not be 'software system', it is a 'System' which depicts the blueprint of the enterprise's overall business activities with answers to the basic questions like What, Who, When, Where and How. Enterprise Architecture has multiple layers and implementation of software and IT systems is one such layer. To ensure that the stakeholders involved in different layers get the accurate view of the principles, strategies and guidlines, it is important to identify, analyze and consider these NFAs early on in the EA Framework development lifecycle.

Sunday, March 25, 2018

Securing the Operational Technology (OT) - The Challenges

OT - Overview

Operational Technology(OT) is generally technology used in the manufacturing or operational floor. The OT has evolved considerably in the recent years from pure mechanical technology to data-driven technologies like Robotic Process Automation (RPA) leveraging IOT, Machine Learning and Artifiial Intelligence. The impetus from the Industrial IOT (IIOT) brings more and more automation capabilities and the connected behavior into the manufacturing floor. Thus the adoption of IT and related technologies in OT is now the common norm and so the need for alignment and convergence with the IT function. 
IOT sensors are deployed everywhere, inside a manufacturing floor, or along the gas pipelines, inside a moving automobile, to monitor the stock movements, etc. Though these dispersed IOT devices perform small functions, the data it produces and the decisions taken based on sucgh data are critical and thus it is being realized that the OT could lead to critical security issues, depending on the size, and critical nature of such enterprise.  

The adoption of IIoT and related technologies brings many benefits to businesses such as smart machines and real-time intelligence from the factory floor - but it also increases the attack surface and requires continuous connectivity between IT and OT. The differing culture and mindset between the IT and OT functions, combined with few other factors often leads to conflicts. 

Hackers and Cybercriminals are now looking at critical infrastructure systems as the targets.  Motivations include holding systems hostage for a ransom, stock price manipulation, denial of production operations, etc. For example, the hackers may take control of your car when on a high way and demand a ransom, which could be life threatening. Similarly, Hackers may get hold of the Energy Grid and shut down the power supply for a region or even nation as a whole. The connected nature of these devices and systems involved in the modern day OT poses serious challenges as they get hooked on to the IT owned network infrastructure, wireless access points, and mobile networks.

Securing the OT

The introduction of new technologies to drive improvements such as production and supply chain efficiency and asset management has led to closer and more open integration between IT and shop floor systems. But the increasing connectivity of previously isolated manufacturing systems, together with a reliance on remote supporting services for operational maintenance, has introduced new vulnerabilities for cyber attack. Not only is the number of attacks growing, but so is their sophistication. As OT security becomes a widely discussed topic, the awareness of OT operators is rising, but so is the knowledge and understanding of OT-specific problems and vulnerabilities in the hacker community.

It’s true that the systems and devices involved in OT are often based on the same technologies as that of IT and as such many of the threats they face are exactly the same. However, it is an open secret that OT security is not the same as IT security. While securing OT systems requires an integrated approach similar to IT, its objectives are inverted, with availability being the primary requirement, followed by integrity and confidentiality. There are certain other important differences as well that mean that the OT infrastucture can not be managed as an extension of the IT infrastructure

Here are some of the areas that makes OT different from IT and thus pose a challenge for the IT Security experts:

1. Visibility:

From the perspective of the organizational units responsible for IT Security function, OT has been somewhat off the radar. This is so, because, the IT function is not involved in the evaluation and selection and procurement of the OT systems. More so, as such OT systems come with a dedicated-networked IT system(s), which could mean even isolated data-centers being setup within the manufacturing floor without the knowledge of the IT function.  Until recently, or even now in certain cases, the IT systems involved in OT are treated as an integral part of production machinery rather than computerized information systems, so the ultimate responsibility of its operation and maintenance, regardless of the cause of potential failure, was assigned to the OT function and not IT function. In most cases, the OT staff often don’t know what types of IT, or IoT devices or equipment that they have as part of their OT ecosystem. 


2. Skill Gap:

One of the biggest challenges facing the industry is deciding who is responsible for OT security - should it be the IT or OT function? Given their background and resources, in many cases IT security teams are being asked to take ownership of coordinating security for OT. However, they typically lack OT specific skills. Defining the security controls / processes for OT systems require indepth knowledge on the OT systems, so that the interests and priorities of the OT function is also taken care of. The cybersecurity industry is projected to reach 1.8 million unfilled roles by 2020. The added complexities of a converged IT/OT security environment could amplify perceived barriers to entry, as organizations struggle to manage the aging workforce of their plant teams with the Millennial generation of new cybersecurity talent.


3. Availability and Safety:

For a Manufacturing company, the production line is very important and its smooth functioning always is very important. Companies lose revenue when their production line is shut down for maintenance, be it planned or unplanned. Nobody wants to disturb OT equipment because any downtime can turn into millions of dollars in lost productivity, highly vocal, disgruntled customers and regulatory fines. Machines must reach a high OEE (overall equipment effectiveness). There is no time to allow IT-style updates and patches that take down equipment.

In many cases, where OT systems are involved in delivering essential services, such as electricity or water, or maintaining safety systems at chemical plants or dams availability is a significant parameter. Even momentary non-availability could lead to catastrophy in certain cases. Enabling high availability of OT systems and maintaining the confidentiality of some sensitive information processes by those systems require additional security controls. Not only are many of these now-connected OT system components are quite vulnerable to compromise, a failure in one of these also has the possibility of causing a catastrophic effect on human life and property. 


4. Processes:

Safety and security for employees and customers have always been top priorities for the OT function and the processes and guidelines are usually defined keeping that in mind. IT function doesn’t even factor plant or employee physical safety in, except where physical access systems are under their domain. IT’s top priority is to protect the data. OT’s top priority, however, is to protect the availability and integrity of the process with security (confidentiality) coming last. At the same time, the OT system components designed for direct control, supervisory control or the safe operation of manufacturing processes,  could turn out to be a safety hazard, even if any component or subsystem  involved compromised. Business systems are also critical but their failure is unlikely to result in the uncontrolled release of hazardous materials or energy. 


5. Legacy: 

It is not uncommon that the computer and related software systems used as part of the OT are used over a decade without being replaced or made any change. These computers and softwares are designed for certain specific functions of interfacing with the other plants and equipments involved in the manufacturing process. It largely depends on the plant or equipment vendor to come out with software and related IT hardware enhancements, otherwise, such systems may not be compatible with the upgraded IT hardware or the OS. Consequently, such systems would be vulnerable to a wide range of cyber-threats that have already been mitigated on the systems used in IT function. This is more so


6. Disparate Technologies:

Until recently, or even now in most cases, the OT architectures run on a separate and isolated infrastructure and as such they have been traditionally isolated from the Internet. One of the reasons for this is because these systems are often hard wired to work with a plant / equipment and to receive and process signlas received and disseminate instructions back to various components. Some OT systems are already only supporting obsolete, insecure operating systems. OT system vendors also do not feel obliged to increase the security capabilities of their systems. Something as benign as an active system scan can cause these devices to fail, which can have serious if not catastrophic results.

System-dedicated networks, multiple domains and dedicated supporting systems require more resources to achieve a maturity level comparable with IT. It also greatly increases the complexity in monitoring and maintaining security levels. The sophisticated nature of OT infrastructure technologies means that most IT security and threat intelligence solutions don’t have visibility into, let alone the ability defend against attacks on critical infrastructures. This creates a challenge in defining and implementing coherent security policies across production plants


7. IIoT Impact: 

The Industry 4.0 revolution is having a great impact on the manufacturing environments. It offers significant opportunities for improving production effectiveness; in particular, based on continual, online information about manufacturing processes and equipment. However, the utilization of new IoT technologies also has an impact on security. It’s not just about networks of course, there are loads of components, including things like sensors and actuators (transducers) and ‘smart things’, fog nodes,(industrial and intelligent) IoT gateways, IoT platforms and so forth. And for IT some of these components are “different” from the cyber security perspective they are used to by the way. New protocols (including wireless) or mesh network architectures increase the number of potential access points to the network and require a different approach to security.

8. Culture:

The IT function responsible for maintaining and securing the Information and related Resources, help ensuring the data Confidentiality, Integrity and Availability aspects and in the process protect corporate information and related assets including networks from cyberattacks. They're less familiar with the OT space, and often display little interest in knowing what their counterparts do to keep it safe and operational. In contrast, OT function monitors and fixes issues in highly complex and sensitive industrial plants with maintaining operational safety, reliability, and continuity as the top priorities. They don't deal or work with IT function, and certainly don't want them to get involved in their operational issues.

Each group is concerned that the other side will wreak havoc in their environment. When there is a need to secure OT against cyberthreats, plant engineers worry that if IT team members get involved, they'll compromise system safety and stability. Unsanctioned changes to these systems might cripple the plant, cause an explosion, or worse. These concerns are justified. After all, when it comes to OT, IT staff members are in uncharted waters. At the same time, the IT function is concerned that vulnerable OT networks will introduce new threats into IT networks, threatening corporate assets, data, and systems.

Conclusion:

As industrial organizations begin to connect their machines to the network, the differences in security requirements for IT versus operational technology (OT) are becoming more important to understand.
There were no good practices and formal regulations for manufacturers on how to provide even minimal security protection on medical devices. 

IT and OT teams are discovering the need to work together in order to deploy cybersecurity solutions throughout the enterprise; from headquarters to remote locations, and the factory floor. Hackers are going after intellectual property, financial data and customer information. CIOs report that intellectual property can constitute more than 80% of company value. Now is the time for OT and IT leaders to develop strong partnerships to promote operational efficiency, safety and competitive advantage.

Neither OT team members nor IT team members are experts in defending OT systems against emerging cyberthreats. Because OT networks were previously disconnected from the external world, engineering staff never had to deal with such threats. Meanwhile, IT staff members who deal with cyberthreats on a daily basis don't fully understand how these new threats will affect OT systems.  Nevertheless, both sides must cooperate, because neither group can protect industrial systems singlehandedly. Given the divergent cultures, technologies, and objectives of IT and OT, the two groups must overcome a significant divide, including mutual suspicion.

To ensure IT and OT collaboration, business-level oversight and leadership is required. More and more organizations are taking senior, experienced engineers from OT business units, usually from under the COO, and moving them under the CIO hierarchy. This interdisciplinary model combines expertise and roles that straddle and unify both sides of the IT-OT fence. Some organizations have taken this one step further. Instead of aligning IT roles under the CIO, they're creating a new C-level role to facilitate this management strategy. 

The higher up the organizational ladder that IT-OT convergence decisions are being made, the better the chances for success in bridging the gap.