Cyber Security Responsibilities of Roles Involved in Software Development

Building secure software is crucial as a vulnerable software would be an easy target for the cyber criminals to exploit. There are people, process and technology forming part of the software supply chain and it is very important that all of these plays a role in securing the supply chain. While process and technology play the role of enablers, it is people who should buy-in and adapt to the mindset of ensuring security in every aspect of their routine work. People's understanding, awareness, and active participation in security practices throughout the software supply chain directly impact the software's overall security posture. This includes developers implementing secure coding techniques, security teams identifying vulnerabilities, and everyone involved staying updated on the latest threats and best practices to prevent potential security breaches.

Whatever said and done, the root cause of a vulnerability in a software ultimately boils down to people, because someone somewhere had missed something and thus a security defect creeps in to the supply chain and shows up as a vulnerability. It could be a missed requirement by the Business Analyst or a simple coding mistake by a developer. So, everyone involved in the software development right from gathering requirements to deployment of the software in production environment need to have the sense of cyber security in what they do. Even those involved in support and maintenance of software systems also has a role in keeping the software secure.

With that context, let's dive into the cyber security responsibilities of various roles involved in the software supply chain.

Product Owner / Product Manager

While some organization may have both the roles some may have only one of the above role. In any case, be it Product Owner or Product Manager, those assuming such role shall ensure to pay attention to security and data protection requirements of the product that they manage.

Product Owners are responsible for delivering maximum value and excellent end user experience. In the SaaS world, they act as a link between stakeholders, development teams, and end users – ensuring the product meets business goals and specific user needs. In today's digital era, security and data protection is a key consideration and is fundamental to the value delivered. Security lapse may easily break the trust and thus make the product useless in no time.

Given this, the Product Owners should know how to protect the product from the dangers and threats of the outside world. To effectively, ensure that the product is reasonably secure, the Product Owners responsibility should set the security and data protection as priority in every phase of the product lifecycle. 

Business Analyst

Business Analyst's role is critical in software development, as it is them who will at the front line, gathering, eliciting and documenting the functional and as well as non-functional requirements for a software product. It will be most beneficial in terms of efforts, if the business analyst could anticipate and call out potential data protection and security requirements for a software product. 

A business analyst's security responsibilities include: 

• identifying potential security risks within business processes.
• ensuring data privacy by analyzing data flows.
• recommending security controls during project planning.
• communicating security concerns to stakeholders.
• staying updated on emerging security threats to incorporate into their analysis.

Essentially the business analysts should act as a bridge between business needs and security requirements. Depending upon the sensitivity and criticality of the domain that the software product caters to, the the responsibilities may extend beyond what is stated above.

Software / Solution Architect 

Software and solution architects play distinct but intertwined roles in developing and implementing IT solutions. Software architects focus on the design and implementation of software components, while solution architects bridge the gap between business needs and technical solutions, ensuring alignment across the entire IT landscape.

Software and Solution Architects play a critical role in ensuring cybersecurity within the software supply chain. Their responsibilities span multiple areas, including designing secure architectures, enforcing compliance, and mitigating risks associated with third-party dependencies. 

Here are some key responsibilities of Software and Solution Architects:

• Ensure zero-trust architecture principles are embedded in design.
• Define and implement security controls for third-party integrations and dependencies.
• Integrate automated security testing (SAST, DAST, SCA) into CI/CD pipelines.
• Conduct risk assessments for third-party software components.
• Monitor for vulnerabilities in open-source and third-party libraries.
• Enforce code signing and provenance verification.
• Establish remediation workflows for compromised dependencies.
• Ensure compliance with NIST 800-161, ISO 27001, and / or such other supply chain security frameworks.
• Align the solution design and security practices with applicable government regulations.

At a minimum, the Software and Solution Architects shall ensure integration of security in the early stages of design and adherence to the Secure Software Design practices which include implementation of Secure Defaults, Least Privilege Principle, Defense in Depth, Secure Configuration Management and Security Testing.

Software Developers

Software developers are the ones who create the application in line with the business requirement and the technical design by writing code. It is important that they understand and interpret the business requirement and technical design in the same way the business analysts and architects have envisioned. 

Off late exploitation of vulnerabilities has been among the most used methods by the cyber criminals. Given that trend, software developers play a crucial role in creating / building secure software, ensuring that the applications remain resilient against cyber threats. Their responsibilities span across secure coding, dependency management, and proactive risk mitigation. 

Here are the key responsibilities of software developers:

• Ensure strict adherence to the secure coding standards to prevent vulnerabilities like SQL injection and buffer overflows.
• Scan software with automated security testing tools (SAST, DAST, SCA).
• Ensure secure CI/CD pipelines to prevent unauthorized code injections.
• Validate checksums to ensure integrity of downloaded dependencies.
• Use lock files to prevent unintended updates to third-party libraries.
• Enforce code signing to verify authenticity of software components.
• Use artifact signing to prevent tampering.
• Develop remediation workflows for compromised dependencies.

QA engineers / Testers

A Software QA Engineer plays a crucial role in security by ensuring software is free from  vulnerabilities. More specifically, their role is very relevant in preventing various injection vulnerabilities by ensuring that the inputs from all sources are properly sanitized and validated before processing. Besides, they are expected to ensure basic authentication and authorization, password rules, MFA requirement, data leak prevention, etc.

The key responsibilities of QA Engineers include:

• Ensuring that proper authentication and authorization is in place.
• Sensitive data is identified and restricted to authorized users only.
• All inputs (through all sources) are sanitized and validated at server side, before processing.
• Data in transit is encrypted and sensitive data is not transmitted in plain text
• Review and test documented feature specific security requirements.
• Ensure regulatory compliance requirements are documented and test the same.
• Test Data downloads to ensure that appropriate level data masking, encryption or password protection for the downloaded files are implemented
• Look for bulk downloads, which shall be restricted to authorized users only.
• Ensure that the error / exception messages doesn't reveal any sensitive environment / technology details.
• Ensure that all uploads are restricted for appropriate file types and file size.

DevOps Engineer

DevOps engineers are IT professionals who oversee code releases and the relationship between development and IT operations teams within an organisation. They aim to establish a culture of collaboration between teams that historically have been siloed. DevOps seeks to automate and streamline the build, test and release processes via a continuous delivery pipeline. 

DevOps engineers play a key role in ensuring supply chain security. focus on the continuous integration and continuous deployment (CI/CD) pipeline. With security included, their function transitions to DevSecOps.

Their security specific responsibilities include:

• Ensure that the authentication keys and other secrets associated with the DevOps pipeline are maintained securely, preferably within a Secure Key Management Service.
• Ensure automated static and dynamic application security testing (SAST & DAST) is performed to ensure that the code and the dependent components are free from any vulnerabilities.
• Ensure that the packaged image or code is free from vulnerabilities by performing automated scanning.
• Review and ensure that the deployment script is free from any external injections.
• Ensure that all changes to the deployment scripts impacting the infrastructure configuration are subject proper change management process with requisite approvals.

Production Support / Help Desk Engineer

The production support engineers are the ones who face the customers who report issues in production systems. They extend L1 support and to understand and diagnose the issues reported they may need additional inputs / data for which many organizations just grant them read only access to production databases. This would be the biggest risk, as they are the easy targets for the hackers to gain access to the database. While read-only access may protect the database from unauthorized modification, it would not prevent from data leakage.

Ideally, production support engineers should never have direct access to database, instead they may have a CRM kind of controlled interface to query data pertaining to the one customer (or entity) at a time. Such interface shall have a log of all activities performed.

Here are some of the key responsibilities of the production support / helpdesk engineer:

• Ensure to establish the identity of the caller / customer being serviced and share only the data pertaining to such customer or entity.
• Ensure that while sharing such data, sensitive data is appropriately masked.
• If access to database is absolutely necessary, request for temporary access, so that such credentials are revoked immediately after its intended use.
• Use MFA and / or stronger password and keep the credentials safe.
• Never leave the system unattended.

Conclusion

Each role in the software development lifecycle has a unique set of responsibilities when it comes to cybersecurity. By understanding and implementing these responsibilities, software developers can significantly enhance the security posture of their applications, ensuring a safer digital environment for all.

Remember, cybersecurity is a team effort—everyone plays a part in keeping data safe!

Building Secure Software - Integrating Security in Every Phase of the SDLC

The software development lifecycle (SDLC) is a process for planning, designing, building deploying and maintaining software systems that has been around in one form or another for the better part of the last 6 decades. While the phases of SDLC executed in sequential order seem to describe the waterfall software development process, it is important to realize that waterfall, agile, DevOps, lean, iterative, and spiral are all SDLC methodologies. SDLC methodologies might differ in what the phases are named, which phases are included, or the order in which they are executed.

A common problem in software development is that security related activities are left out or deferred until the final testing phase, which is too late in the SDLC after most of the critical design and implementation has been completed. Besides, the security checks performed during the testing phase can be superficial, limited to scanning and penetration testing, which might not reveal more complex security issues. By adopting shift left principle, teams are able to detect and fix security flaws early on, save money that would otherwise be spent on a costly rework, and have a better chance of avoiding delays going into production.

Integrating security into SDLC should look like weaving rather than stacking. There is no “security phase,” but rather a set of best practices and tools that should be included within the existing phases of the SDLC. A Secure SDLC requires adding security review and testing at each software development stage, from design, to development, to deployment and beyond. From initial planning to deployment and maintenance, embedding security practices ensures the creation of robust and resilient software. A Secure SDLC not only helps in identifying potential vulnerabilities early but also reduces the cost and effort required to fix security flaws later in the development process. Despite the perceived overhead that security efforts add to, the impact from the security incident could be far more devastating than the effort of getting it right the first time around. 

1. Planning

The planning phase sets the foundation for secure software development. During this phase, it’s essential to clearly establish the security strategy and objectives and develop a security plan, which shall be part and parcel of the product or project management plan. While doing so, it is important to take into account the contractual obligations with the client, regulatory requirements as may be relevant and applicable for the functional domain and the country and region where the product or project is likely to be executed and deployed. It is also important to define and document appropriate security policies as relevant to the project / product.  The established Security strategies, objectives and the related implementation plan shall be diseminated to all stakeholders, so that they are aware of their roles and responsibilities in meeting the objectives and achieving these goals.

2. Requirements

In the requirements phase, security requirements should be explicitly defined and documented. Collaborate with stakeholders to understand the security needs of the application. Identify compliance requirements and industry standards that must be adhered to. Incorporate security considerations into functional and non-functional requirements. Ensure that security requirements are clear, measurable, and testable.

Security requirement gathering is a critical part of this phase. Without this effort, the design and implementation phases will be based on unstated choices, which can lead to security gaps. You might need to change the implementation later to accommodate security, which can be expensive.

During this phase, the Business Analysts shall gather relevant security requirements various sources and such requirements are of the following types:

• Security Drivers: The security drivers determine the security needs as per the industry standards, thereby shaping security requirements for the given software project or product. The drivers for security requirements include regulatory compliance like SarbanesOxley, Health Insurance Portability and Accountability Act (HIPAA),  PCI DSS, Data Protection Regulaations etc.; industry regulations and standards like ISO, OASIS etc.; company policies like privacy policies, coding standards, patching policies, data classification policies etc.; and security features like authentication and authorization model, role-based access control, and administrative interfaces etc. The policies when transformed to detailed requirements demonstrate the security requirements. By using the drivers, managers can determine the security requirements necessary for the project. 
• Functional Security Requirements (FSR): FSRs are the requirements that focus on the given product or project. The requirements for the FSRs can be gathered from the customers and end users. This may also contain security requirements as derived from the Security Drivers. These requirements are normally gathered by means of misuse cases which capture requirements in negative sense, like what should not happen or what should not be permitted. To ensure that the FSR is fully gathered, it is essential that the involved Business Analysts shall have the requisite level of exposure in Security related aspects or shall collaborate with Security Analysts.

3. Design

The design phase is where the Architects document the technical aspects of the software. This is a critical phase for incorporating security aspects with technical and implementation details into the software architecture. In this phase, the Architects shall consider the Drivers and FSRs documented in the Software Requirements Specification as documented in the previous phase. The following are some of the Non Functional security requirements that the Architects shall take into account while designing the Software Architecture.

• The Security dimension: The Architects shall Identify and document the security controls to be considered for protecting the system and interfaces exposed for third parties. For example, component / module segmentation strategy, the types of identities (both human and non-human) needed, authentication and authorization scheme, and the encryption methods to protect data, etc. 
• Shared Responsibilities: It's important to understand and take into account the shared responsibility model of the cloud service provider or such other infrastructure service provider. It will be unnecessary to implement security controls within the system where the service provider has accepted the responsibility. However, it would be appropriate to factor aa conditional compensating controls, so that in the event of any breach on the service provider end, the compensating control could kick-in.
• System Dependencies: Clearly identify the third party or open source components or services to be used after evaluating the security risks associated with such components and services. If appropriate consider factoring additional security controls to compensate any known risks exposed by such components / services.
• Security Design Patterns: Design Patterns offer solutions for standard security concerns like segmentation and isolation, strong authorization, uniform application security, and modern protocols. The Architect shall explicitly call out the relevant and appropriate design patterns to be used by the development teams.

4. Development

During the development phase, secure coding practices are paramount. Educate developers on secure coding techniques and provide them with tools and resources to write secure code. The Developers shall be required to use static code analysis tools to identify and remediate security issues early in the development process. The developers shall have the mindset to expect the unexpected, so that all current and future scenarios are considered while building the software.

The following are some of the common practices that the developers shall adhere to while building the software:

• Input Validation: One of the most common entry points for attackers is through improperly validated inputs. Ensure that all user inputs are thoroughly validated and sanitized. Implement strong input validation techniques to prevent injection attacks, such as SQL injection and cross-site scripting (XSS). It is common that there would be multiple entry points for receiving inputs (e.g. web and mobile user interfaces, APIs, uploads, etc), in which case, the validation and sanitization shall be implemented in all such entry points. 
• Write just enough code: When you reduce your code footprint, you also reduce the chances of security defects. Reuse code and libraries that are already in use and have been through security validations instead of duplicating code.
• Use Parameterized Queries: SQL injection attacks can be devastating, allowing attackers to execute arbitrary SQL code. To prevent this, always use parameterized queries or prepared statements when interacting with databases. This approach ensures that user inputs are treated as data, not executable code.
• Implement Authentication and Authorization: Authentication verifies the identity of users, while authorization determines their access levels. Use strong authentication mechanisms, such as multi-factor authentication (MFA), and implement role-based access control (RBAC) to ensure that users only have access to the resources they need.
• Deny-all approach by default: Create allowlists only for entities that need access. For example, if you have code that needs to determine whether a privileged operation should be allowed, you should write it so that the deny outcome is the default case and the allow outcome occurs only when specifically permitted by code.
• Encrypt Sensitive Data: Encryption is a critical component of secure coding. Encrypt sensitive data both at rest and in transit to protect it from unauthorized access. Use industry-standard encryption algorithms and ensure proper key management practices. With the quantum computing getting closer to commercial adoption, it is time to consider quantum safe encryption methods.
• Secure Session Management: Session hijacking can compromise user accounts. Implement secure session management practices, such as generating unique session IDs, using HTTPS, and setting appropriate session timeouts. Ensure that session tokens are securely stored and transmitted.
• Regularly Update and Patch Dependencies: Outdated libraries and dependencies can introduce vulnerabilities into your software. Regularly update and patch third-party libraries and components to ensure that known security flaws are addressed promptly.
• Implement Error Handling and Logging: Proper error handling and logging are crucial for identifying and mitigating security issues. Avoid exposing sensitive information in error messages. Use logging to track suspicious activities and potential security breaches.
• Conduct Code Reviews: Peer code reviews are essential steps in the development process. Conduct regular code reviews to identify potential security issues. Use automated tools for static and dynamic analysis to uncover vulnerabilities.

5. Testing

The testing phase of the SDLC typically happens after all new code has been written, compiled and the application is deployed in a test environment. This is another opportunity to perform tests in near production environment, even if earlier testing of source code already happened. The testing phase is where security vulnerabilities are identified and addressed. While there exist tools for performing securit testing, the human testers are required to be aware of various security scenarios and accordingly align their test strategy, choice of tools, the level of coverage, etc. Following are some of the widely practiced security testing methods, besides manual functional testing:

• Static Application Security Testing (SAST): SAST is a software testing method that analyzes an application's source code for vulnerabilities. It's also known as static analysis or white box testing. SAST analyzes an application's source code, byte code, and binaries. SAST can help identify vulnerabilities such as buffer overflows, SQL injection, and cross-site scripting (XSS). SAST is a white-box testing method that looks for vulnerabilities inside the application.
• Dynamic Application Security Testing (DAST): DAST is a black-box testing method that analyzes web applications for vulnerabilities by simulating attacks. DAST tests running applications in real-time to find security flaws. DAST evaluates applications from the "outside in". DAST tests for critical threats like cross-site scripting (XSS), SQL injection (SQLi), and cross-site request forgery (CSRF).
• Penetration Testing: A penetration test, also known as a pen test, is a simulated cyber attack against your application to check for exploitable vulnerabilities. The goal is to determine if the application is secure and can withstand potential attacks.
• Fuzz Testing: Fuzz testing is a software testing method that uses automated tools to identify bugs and vulnerabilities in web applications by feeding unexpected or invalid data to see how the application behaves or responds. The goal is to induce unexpected behavior, such as crashes or memory leaks, and see if it leads to an exploitable bug. Fuzz testing can uncover a wide range of vulnerabilities, including those that may not be detected through other testing methods.

6. Deployment

Securing the deployment phase of the Software Development Lifecycle (SDLC) involves ensuring that the software is ready for use and configured securely. This includes implementing access controls to protect the environment used for build and deployment, monitoring for vulnerabilities, and responding to security incidents. The following are some of the best practices to be practiced:

• Environment Hardening: Secure the deployment environment by disabling unnecessary services and applying security patches. Build agents are highly privileged and have access to the build server and the code. They must be protected with the same rigor as the workload components. This means that access to build agents must be authenticated and authorized, they should be network-segmented with firewall controls, they should be subject to vulnerability scanning, and so on.
• Secure the Source Code Repository: The source code repository must be safeguarded as well. Grant access to code repositories on a need-to-know basis and reduce exposure of vulnerabilities as much as possible to avoid attacks. Have a thorough process to review code for security vulnerabilities. Use security groups for that purpose, and implement an approval process that's based on business justifications.
• Protect the deployment pipelines: It's not enough to just secure code. If it runs in exploitable pipelines, all security efforts are futile and incomplete. Build and release environments must also be protected because you want to prevent bad actors from running malicious code in your pipeline.
• Up-to-date Software Bill of Materials (SBOM): Every component that's integrated into an application adds to the attack surface. Ensure that only evaluated and approved components are used within the application. On a regular basis, check that your manifest matches what's in your build process. Doing so helps ensure that no new components that contain back doors or other malware are added unexpectedly.

7. Maintenance

Security does not end with deployment; it is an ongoing process. During the maintenance phase, continuously monitor the application for security threats and vulnerabilities. Apply security patches and updates promptly. Conduct regular security audits and reviews to ensure compliance with security policies and standards. Educate users on security best practices and respond to security incidents swiftly.

Conclusion

Building secure software requires a holistic approach that integrates security into every phase of the SDLC. By adopting these best practices, organizations can create resilient applications that protect sensitive data and withstand cyber threats. Remember, security is a continuous journey, and staying vigilant is key to maintaining a secure software environment.

Managing Third-Party Risks in the Software Supply Chain

Supply chain attacks might leverage multiple attack techniques. Specialized anomaly detection technologies, including endpoint detection and response, network detection and response and user behavior analytics can complement the broader scope covered by security analytics on centralized log management/SIEM tools. 

The software supply chain encompasses many entities involved in the development, production and distribution of IT products and services, including hardware manufacturers, software developers, cloud service providers and even the vendors used by direct suppliers (fourth parties). Organizations rely on numerous third-party vendors and service providers to build, deploy, and maintain their software systems. While this interconnectedness brings numerous benefits, it also introduces significant risks that can have far-reaching consequences. 

The myriad of third party risks such as, compromised or faulty software updates, insecure hardware or software components and insufficient security practices, expand the attack surface of the organization. A security breach in one such third party entity can ripple through and potentially lead to significant operational disruptions, financial losses and reputational damage to the organization.

In view of this, securing not just their own organizations, but also the intricate web of suppliers, vendors and partners that make up their cyber supply chain is not just an option, but a necessity. It is needless to state that managing the third party risks is becoming a big challenge for the Chief Information Security Officers. More to it, it may not just be enough to maanage third-party risks but also fourth party risks as well. Aligning third-party vendors with business objectives is a critical supply chain security priority.

Understanding Third-Party Risks

Third-party risks are potential threats that originate from outside vendors, suppliers, or service providers that an organization relies on. Third-party risk involves the direct suppliers and vendors an organization engages with for products and services used in the software supply chain. These entities often have privileged access to sensitive data, making them prime targets. Fourth-party risk extends further to include the vendors and service providers that the third party rely on to deliver the products or services. This indirect relationship can obscure visibility into potential vulnerabilities, posing challenges for organizations in managing these risks.

These risks can include data breaches, service disruptions, and noncompliance with regulations. The common types include:

• Operational Risks: The risk of a third-party causing disruption to the business operations. This is typically managed through contractually bound service level agreements (SLAs) and business continuity and incident response plans.  Depending on the criticality of the vendor, you may opt to have a backup vendor in place, which is common practice in the financial services industry.
• Cybersecurity Risks: The risk of exposure or loss resulting from a cyberattack, security breach, or other security incidents. Cybersecurity risk is often mitigated via a due diligence process before onboarding a vendor and continuous monitoring throughout the vendor lifecycle.
• Compliance Risks: The risk of a third-party impacting your compliance with local legislation, regulation, or agreements. This is particularly important for financial services, healthcare, government organizations, and business partners. 
• Financial Risks: The risk that a third party will have a detrimental impact on the financial success of your organization. For example, your organization may be unable to sell a new product due to poor supply chain management.
• Reputational risk: The risk of negative public opinion due to a third party. Dissatisfied customers, inappropriate interactions, and poor recommendations are only the tip of the iceberg. The most damaging events are third-party data breaches resulting from poor data security, like Target's 2013 data breach.

Best Practices for Managing Third-Party Risks

Effectively managing third-party risks involves a proactive approach that includes the following best practices:

1. Identify and Classify Third-Party Vendors

First, identify all third-parties who play  role in the software supply chain and classify them based on their criticality of the components and services that are sourced from them . It would be also be importnt to consider the criticality of the system for which such components or services are consumed for. Like most risk mitigation plans, a sound strategy involves categorizing the threats by priority. In terms of third parties, the goal is to determine which third-party relationship is riskiest. This helps prioritize risk management efforts by planning and allocating necessary resources.

2. Conduct Thorough Due Diligence

As  next step, conduct a comprehensive due diligence to assess the security posture, financial stability, compliance with regulatory requirements, and overall reliability of the third-parties. This process should include reviewing their security policies, secure coding practices, supply chain risk management plans, previous incident reports, and financial statements. Based on the assessment, either require the third-party to implement necessary policies, processes and controls or put in place appropriate compensating controls to keep the risk under control. Besides, the duediligence shall be conducted in periodic intervals or upon happening of any event or incident impacting the components or services consumed.

3. Establish Clear Contracts and SLAs

Another important step is to ensure that contracts and Service Level Agreements (SLAs) are executed with the third parties and the contract should clearly contain clauses detailing the expectations, responsibilities, indemnities, and penalties. Such contracts should cover aspects such as data security, incident response, confidentiality, and applicable regulatory compliance. The entity shall also be required to report or notify significant security incidents within reasonable time, so that appropriate action as may be necessary to prevent the cascading impact of such incident can be taken.

Mapping your most critical third-party relationships can identify weak links across your extended enterprise. But to be effective, it needs to go beyond third parties. In many cases, risks are often buried within complex subcontracting arrangements and other relationships, within both your supply chain and vendor partnerships. Illuminating your extended network to see beyond third parties is critical to assessing, mitigating and monitoring the risks posed by sub-tier suppliers.

Furthermore, it’s recommended that companies include a “right-to-audit” clause in any contract. This enables the hiring entity to conduct an audit on the third party, checking to see if signed contract is actually being followed. Such a clause also allows companies to assess whether new clauses need to be added to the contract in the future.

4. Monitor and Assess Continuously

Continuous monitoring of third-party vendors is essential to ensure ongoing compliance and risk management. This involves regular audits, assessments, and reviews of the vendor's performance, security practices, and financial health. Besides, after analyzing your organization’s relationships with vendors and suppliers and grouping them based on their risk level, the risk management strategy should be reviewed and revised to make it more efficient. Properly managing supplier risks is essential for interconnected businesses and helps address cybersecurity vulnerabilities throughout the supply chain ecosystem.

Third-party management isn’t just about monitoring for cybersecurity weaknesses and providing compliance advisory services of third parties, although such concerns are important. Third-party risk management includes a whole host of other aspects such as ethical business practices, corruption, environmental impact, and safety procedures to name a few. How third parties operate can directly impact the reputation of the company hiring them.

5. Implement a Third-Party Risk Management (TPRM) Program

Develop and implement a comprehensive third-party risk management program that includes policies, procedures, and tools to manage and mitigate risks. This program should be integrated with the organization's overall risk management strategy and updated regularly to address emerging threats and vulnerabilities. A well-designed third party risk management program framework provides a win-win situation. It helps in predicting third-party risks and high-risk vendors prior to risk assessment. The risk management planning framework saves time and provides insightful risk assessment.

Effective TPRM requires expertise in information security, privacy, sanctions, ESG and other specialized fields. While some businesses have this expertise in-house, many organizations gain these capabilities and add capacity to their risk management function through outsourcing.

6. Foster Strong Relationships and Communication

Suppliers who feel valued are more likely to work with you to solve problems, share information, and adapt to changes. This can lead to a more resilient supply chain. Communication between stakeholders and external suppliers can improve the process by bringing more creative ideas to the table. By fostering open communication and transparency, you can create a foundation of trust that enables better information sharing and risk management. Regular meetings, feedback sessions, and open channels of communication can help address issues promptly and improve overall risk management.

7. Prepare for Incident Response

In an ideal world, a well-defined supply chain incident response plan, complete with well-tested procedures, SBOMs, and comprehensive software inventories would be in place. However, reality often catches us off-guard. Despite best efforts, incidents may still occur. This is where timely notification of the incidents by the third-party is essential. The incident response plan should include steps for notifying affected parties, containing the incident, and conducting post-incident analysis.

Conclusion

Managing third-party risks in the software supply chain is a critical aspect of modern business operations. By adopting these best practices, organizations can safeguard their operations, maintain regulatory compliance, and build resilient partnerships with their third-party vendors. In an era where cyber threats are ever-evolving, proactive risk management is the key to staying ahead.

While companies can implement a wide range of strategies to manage third-party risks, there’s no guarantee of safety from breaches. Therefore, it’s important to stay vigilant, as third-party risks are now at the forefront of organizational threats.

The Perils of Security Debt: Serious Pitfalls to Avoid

In today's fast-paced digital world with ever evolving cyber threats, businesses face an increasing number of cyber security incidents. As organizations strive to remain agile and competitive, there’s often a tendency to prioritize speed and innovation over security. This can lead to what's known as "security debt"—the accumulation of risks and vulnerabilities that are neglected in the race to deploy new features or systems quickly. For Boards and C-suite executives, understanding the perils of security debt is crucial to ensuring the long-term health and safety of their organizations. Here’s a deep dive into why security debt is risky and how it can be managed effectively.

Defining Security Debt

In some ways, security and technical debt are similar: If you don’t pay the debt off, you’ll end up paying just interest without getting to the principal. But security debt doesn’t just “impede future development” of a project. Instead, an accumulating pile of vulnerabilities puts your organization at a much greater risk of malicious cyber exploits. Just as financial debt accrues interest over time, security debt can accumulate increased risks, leading to significant consequences if not addressed promptly.

Security debt is caused by a failure to “build security in” to software from the design to deployment as part of the SDLC. Security debt accumulates when a development organization releases software with known issues, deferring the redressal of its weaknesses and vulnerabilities. Sometimes the organization skips certain test cases or scenarios in pursuit of faster deployment and in the process failing to test software thoroughly. Sometimes the business decides that the pressure to finish a project is so great that it makes more sense to release now and fix issues later. Later is better than never, but when “later” never arrives, existing security debt becomes worse.

Consequences of Security Debt

1. Increased Vulnerability to Attacks: Neglecting security measures can leave your systems exposed to cyber-attacks like data breaches, ransomware, and insider threats. It broadens the attack surface and thus increasing the likelihood of cyber attacks. It is needless to stress that such attacks can result in loss of sensitive data, financial damage, and reputational harm.

2. Regulatory Non-Compliance: If your organization bypasses security protocols, you might find yourself on the wrong side of compliance regulations such as GDPR, HIPAA, or CCPA or such other applicable regulations. Any compromise on non-compliance such regulatory requirmenets can result in hefty fines and legal repercussions including impact on brand reputation.

3. Higher Remediation Costs: Like in case defects, fixing defects early in the lifecycle of the software would be a lot cheaper. Also, the longer security debt goes unpaid, the software complexity would increase, makint it harder and more expensive to address it. Fixing vulnerabilities retroactively often requires more resources than if they had been managed proactively. This holds good for process related gaps as well.

4. Erosion of Customer Trust: Customers are increasingly aware of privacy and security issues. A security breach not only impacts operations but also damages customer trust and loyalty, which can be difficult to rebuild.

5. Decreased Resilience: The more debt an organization carries, the less resilient it becomes to new threats. New vulnerabilities continue to emerge, and if an organization is already burdened with significant security debt, it will struggle to keep up with the evolving threat landscape.

Strategies to Manage and Mitigate Security Debt

1. Assess and Track Security Debt: Assessing an organization's in-depth security situation is the first step toward paying off security debt. Organizations should locate and record and track any security gaps, weak points, and vulnerabilities in their networks, systems, and applications. Such known security gaps shall be managed as a risk.

2. Incorporate Security into Design & Development Cycles: Emphasize a DevSecOps approach where security is integrated into every phase of development. Integrate automated vulnerability scanning and penetration testing into your workflow to identify and address potential security flaws early in the SDLC. Regular security assessments and automated testing can catch vulnerabilities early in the cycle. Make Security as a business priority, so that security gaps are not compromised in favour of other business priorities. 

3. Prioritize Risk Assessments: Conduct regular and thorough risk assessments to identify and rank potential threats. This helps in directing resources towards the most pressing security concerns. This way, the accumulated security debt can be kept under check.

4. Collaborate with External Security Experts: Organizations may find it advantageous to work with outside security specialists or consultants to address challenging security problems and pay off security debt in certain situations. Penetration testers, security reviewers, and external security assessors can offer insightful analysis and helpful suggestions for strengthening safeguards and resolving vulnerabilities.

5. Invest in Continuous Monitoring: Implement continuous security monitoring tools to detect and address vulnerabilities in real-time. This proactive approach minimizes the potential for unaddressed issues to evolve into major threats.

6. Foster a Security Culture: Encourage a company-wide security mindset. Educate employees at all levels about the importance of security practices and provide regular training to keep security at the forefront of everyone’s mind. Foster an environment where team members feel comfortable reporting potential security issues without fear of retribution. Transparency is key to addressing vulnerabilities effectively.

7. Allocate Budget for Security Improvements: Ensure that your organization allocates sufficient budget for ongoing security initiatives. Recognize that investing in security today can save substantial costs and risks in the future. Invest in regular and periodic training so that the employees stay updated with the latest security trends and threats. Knowledge is the first line of defense.

Leadership's Role in Addressing Security Debt

Great leadership is the beacon that not only charts the course but also ensures your crew – your IT team, support staff, and engineers – are well-prepared to face the challenges ahead. It instills discipline, vigilance, and a culture of security that can withstand the fiercest digital storms.

The Board and leadership must understand and champion the importance of security for the organization. By setting the tone at the top, they can drive the cultural and procedural changes needed to prevent the accumulation of the security debt. Periodic review and monitoring of security metrics, and identifying & tracking security debt as a risk can help keep the organization accountable and on track.

Conclusion

Security debt may be an unseen burden, but its impacts are real and potentially devastating. For Boards and executive teams, recognizing and addressing security debt is not just a technical necessity but a critical component of strategic resilience. Investing time and resources into managing this debt will not only safeguard your organization today but also fortify it against the evolving challenges of tomorrow. By recognizing the challenges presented by security debt, employing a side-by-side approach to remediating both critical and other vulnerabilities, and employing appropriate risk scoring, vulnerability intelligence and related techniques, organizations can reduce both their security debt and exposure to potential attacks.

Setting up a Security Operations Center (SOC) for Small Businesses

In today's digital age, security is not an option for any business irrespective of its size. Small Businesses equally face increasing cyber threats, making it essential to have robust security measures in place. A SOC is a dedicated team responsible for monitoring, detecting, and responding to cybersecurity incidents in real-time. It acts as the frontline defense against cyber threats, helping to safeguard your business's data, reputation, and operations. By establishing a SOC, you can proactively address security risks and enhance your overall cybersecurity posture.

The cost of setting up a SOC for a small business may be prohibitive, in which case, the businesses may look at engaging Managed Service Providers for the whole or part of the services. For instance, if the business can afford to have its own team, then they can consider subscribing to cloud based technology services / tools to facilitate the SOC operations.

Here’s an attempt to provide guidance in setting up a SOC, even on a limited budget.

The Objectives

Before setting up a SOC, it's crucial to outline the objectives. The People, Process and Technology to be used for the SOC largely depends on the objectives. Here are some common goals for a small business SOC:

• Protecting assets: The SOC monitors and protects the organization's assets, such as intellectual property, personnel data, and business systems.
• Responding to incidents: The SOC identifies and responds to security incidents, analyzing suspicious activity and taking action to contain and remediate the incident.
• Gathering threat intelligence: The SOC gathers and analyzes threat intelligence to stay up to date on cyber threats and vulnerabilities.
• Managing vulnerabilities: The SOC identifies and assesses vulnerabilities in the organization's IT infrastructure and systems, and prioritizes and remediates them.
• Ensuring compliance: The SOC ensures that the organization complies with relevant security regulations and standards.

The SOC Team

Building a competent SOC team is essential for the success of security operations. Depending on the budget and resources, the SOC team may include:

• SOC Manager: Develops the organizzaation's security strategy, including hiring, processes, and technology. They provide technical guidance and managerial oversight.
• Threat Hunters: Proactively look for threats that may have evaded automated detection. They use data analysis, threat intelligence, and experience to uncover potential breaches and hidden vulnerabilities.
• Security Analysts: Monitor security events and alerts from various sources, such as intrusion detection and prevention systems (IDPS), security information and event management (SIEM) systems, and endpoint detection and response (EDR) solutions.
• Incident Responders: Focus on containment, eradication, and recovery of confirmed cybersecurity incidents. They need specific skills in incident management, crisis control, and restoring systems to normal operations.
• Threat Intelligence Analysts: Use threat intelligence to perform assessments to discover the primary aim of the attack and which systems were affected.
• IT Support: Assist with deploying and maintaining security tools and technologies.
• Complince Auditor: Ensures that SOC members are following protocols and adhering to government or industry regulations. They play a key role in standardizing processes within a SOC.

If staffing a full team is not feasible, consider outsourcing certain functions to managed security service providers (MSSPs) or utilizing part-time consultants. Alternatively, depending on the volume of work, some roles may be combined and rolled up to one employee.

Essential Tools & Technologies

Equipping your SOC with the right tools and technologies is critical. Here are some essential components:

• Security Information and Event Management (SIEM) System: Collects and analyzes logs & other associated data from various infrastructure assets including applications for the purpose of providing real-time alerts and insights. SIEM is a fundamental technology that forms the core of a SOC. Modern SIEM tools have the ability to leverage Artificial Intelligence capabilities so as to correlate data from different sources and help the SOC team make a better decision.
• Intrusion Detection and Prevention Systems (IDPS): Analyzes network traffic to identify and prevent cyber threats. IDPSs can be either a hardware device with pre-loaded software tools or a virtual service, and they can use various methods including to identify attacks, such as signature matching, anomaly detection, behavioral analysis, and threat intelligence. Here again, AI is being explored to play a vital role to improve the efficiency and effectiveness of the detection and prevention.
• Endpoint Detection and Response (EDR) Tools: Helps organizations detect, contain, and respond to cyberattacks. EDR tools can collect endpoint data from various sources, including on-premises and cloud services. They can also provide SOC teams with remote control over endpoints to perform immediate mitigation.
• Incident Response Tools: Facilitates the investigation and remediation of security incidents. Modern tools can help SOC teams automate routine response tasks, such as isolating compromised endpoints.
• Vulnerability scanners: Detect weaknesses in systems and applications before attackers can exploit them. They can scan networks, systems, and applications for known vulnerabilities and misconfigurations.

In case, you have hosted your applications on the cloud infra, it is likely that your Cloud Service Provider (CSP) offers some or all of the above tools as a service. Ofcourse, subscribing to such services may result in additional cost. While budget constraints may limit the number of tools you can acquire, prioritize those that address your most critical security needs.

SOC Processes

Establishing clear, well-defined processes is vital for the smooth functioning of your SOC. NIST Cyber Security Framework could be a good fit for all businesses and one can define the processes that are essential and relevant considering the size, threat landscape and risk tolerance of the business. Key processes include:

• Incident Detection and Reporting: Define steps for identifying and reporting incidents, including automated alerts and manual reporting procedures.
• Incident Response and Remediation: Outline the actions to take when an incident occurs, including containment, eradication, and recovery.
• Threat Hunting: Proactively search for potential threats and vulnerabilities within your network.
• Regular Audits and Assessments: Conduct periodic reviews to evaluate the effectiveness of your security measures and identify areas for improvement.

Training & Up-skilling

Continuous training and development are essential for keeping your SOC team prepared to handle evolving threats. Offer regular training sessions, certifications, and workshops to enhance their skills and knowledge. Encourage your team to stay updated on the latest cybersecurity trends, tools, and best practices.

Continuous Improvement

Once your SOC is operational, regularly monitor its performance and effectiveness. Collect and analyze data on incidents, response times, and resolution success rates. Use this information to identify areas for improvement and make necessary adjustments. Continuously updating and refining your SOC processes will help you stay ahead of emerging threats.

Conclusion

Setting up a Security Operations Center may seem daunting, especially for small businesses with limited resources. However, by defining clear objectives, assembling a skilled team, investing in essential tools, and establishing robust processes, you can create an effective SOC that enhances your cybersecurity defenses. Proactive monitoring and continuous improvement will help protect your business from cyber threats and ensure long-term success.

The Biggest Predictions for the IT Industry

By Team TechJury

The IT industry is continuously evolving. Thanks to its dynamic nature, we are getting access to improved products and services. Moving forward, the industry is poised for even more growth as developers and IT experts work around the clock to upend what IT is today.

Here are some predictions on what comes next within the industry.

AR For Businesses

The world met augmented reality (AR) in its true form when Pokemon GO was launched in 2016. Aside from video games, AR will be making its way into businesses as well. Firms such as realty companies can use AR to provide virtual and in-depth tours of rooms and homes. Others can use it to create more engaging marketing strategies.

More Jobs In IT

With automation making its way in various industries, there’s no doubting that the growth of AI will penetrate the workplace too. For this reason, we can expect more and more IT-related jobs in the future.

According to recent data, the total number of IT jobs will increase by 13% between 2016 and 2026. Considering the current rate, there might even be more jobs to look out for.

Smarter AI

According to Forbes, the next step for AI is the processing of emotions. By making AI capable of the feat, we can make it even smarter, thus allowing it to do more jobs that only humans are capable of at the moment.

Blockchain Acceptance

Blockchain is one of the emerging trends in the IT industry. Even though some experts believe that it’s a promising technology, it still has a long way to prove their trust. We are yet to see what can blockchain change in this sector.

Meanwhile, blockchain disruptions are already a reality. A good example is the telecom industry. If everything goes according to plan, we should see huge improvements in telecommunication services soon.

These are just some of the current trends and predictions for IT in the coming years. Obviously, exciting things are up ahead for the industry.

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.

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.

The Mobile Phone Is Your Private Property

This morning, when I was on my morning walk, a person came out of a construction site and was requeting me to lend my phone to make a phone call. I was not comfortable lending my phone primarily for three reasons: First he is a stranger to me; Second, he seem to be working in the construction site and he should have sought help from those around in his workplace as they would be more comfortable helping him; Third, my mobile is my private identity and would not want a stranger to use impersonate me. I did not lend my phone on that occasion.

How about you? Would you mind lending your phone for such requests? I understand, the answer will be "it depends." Thank's to "Selfie" feature, seeking help from a stranger to take a snap on the mobile phone is not required any more. Any ways, I thought it would be useful to list out the concerns, so that one can decide how safe is to part with one's smart phone. These apply for stolen / lost mobile phones as well.

Your Phone Contains Sensitive Information

You have your email configured on your mobile and typically, it does not expect you to login every time you use your mail app on your mobile. So lending a phone may allow the stranger gaining access to your emails and depending the duration it remains with such stranger, the impact of such compromise could be larger. Similarly, all your social media accounts do not expect any additional authentication. It is needless to say that what a smart or malicious stranger could do with access to your social media accounts. Exposing all the intimate details of our lives because of a lost, stolen or hacked phone is a serious issue.

Banking / Payment Applications

"There is an App for everything". Yes, every bank and the investment advisors are rolling out their own Apps with pre-stored credentials for the mobile savvy customers. Mobile users, find it convenient to use such an App, without having to login every time. However, the issue of how many such Apps will you install on your mobile phone is an issue to be discussed in a separate blog. For the purpose this blog let us consider the prevailing App culture. Driven by the Digital economy, there are humpteen number of Payment / eWallet Apps out in the store. The user convenience always wins over the security requirements and as such most such Apps doesn't requie a login to initiate a payment. This could be a potential risk one should be aware of and be careful about.

Personal & Corporate Information

If you are working for an organization, it is most likely that you would have setup your corporate email account as well on your smart phone and there you go, you are putting your organization's data / information at risk. Your organization would have a BYOD policy and procedure, stating what precautions you should take on the corporate data that you use or access using your smart phone. If you are an senior level executive, it is likely that you will have access to your organizational applications configured on your mobile. This includes compromise of your or your organization's cloud storage if any configured on the phone.

Illegitimate Calls / Messages

In addition to your device, your mobile phone number (SIM) is very well linked to your identity. As such any calls or message that such a stranger sends using your phone will be logged against your identity and you are responsible and answerable for consequences if any that may arise out of such calls or messages. Even if the activity is legitimate, it may be possible that the other person might call or message you back in future with or without any specific intent.

AVAST did a research in February 2016 and according to them, their researchers were able to recover the following files from the 20 phones that were sold:

• More than 1,200 photos
• More than 200 photos with adult content
• 149 photos of children
• More than 300 emails and text messages
• More than 260 Google searches, including 170 searches for adult content
• Two previous owners’ identities
• Three invoices
• One working contract
• One adult video

Given the ever evolving capabilities of the smart phones, the devices are increasingly becoming one's identity and as such should be handled with care and caution, or else one has to face the consequences that may arise as a result of such compromise.