NL2014909B1 - Enterprise automation system vulnerability assessment. - Google Patents
Enterprise automation system vulnerability assessment. Download PDFInfo
- Publication number
- NL2014909B1 NL2014909B1 NL2014909A NL2014909A NL2014909B1 NL 2014909 B1 NL2014909 B1 NL 2014909B1 NL 2014909 A NL2014909 A NL 2014909A NL 2014909 A NL2014909 A NL 2014909A NL 2014909 B1 NL2014909 B1 NL 2014909B1
- Authority
- NL
- Netherlands
- Prior art keywords
- check
- automation system
- application
- vulnerability assessment
- vulnerability
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0635—Risk analysis of enterprise or organisation activities
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Entrepreneurship & Innovation (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Physics & Mathematics (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Computing Systems (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
An enterprise automation system comprises a plurality of enterprise automation system software modules, a technical management application configured for performing management of the enterprise automation system, and a vulnerability assessment application configured for assessing vulnerabilities in the enterprise automation system. The a vulnerability assessment application is provided on top of a software stack of the technical management application. The vulnerability assessment application comprises a set of checks, each check is configured to determine a presence of a respective vulnerability and check configuration data associated with each check. The vulnerability assessment application is configured to select a subset of the set of checks in accordance with a configuration of the enterprise automation system based on the check configuration data.
Description
Title: Enterprise automation system vulnerability assessment
The invention relates to an enterprise automation system, such as a SAP enterprise automation system, comprising a plurality of enterprise automation system software modules, such as SAP software modules, and to a method of assessing vulnerabilities in an enterprise automation system, such as a SAP enterprise automation system.
In companies and other organisations, such as non-profit or governmental organisations, enterprise automation systems may comprise a plurality of enterprise automation system software modules. For example, in an enterprise such as a company, the automation system may comprise software modules which each perform a task such as finance, controlling, materials management, sales and distribution, plant maintenance, production planning, quality management, project planning, human resource planning, workflow management warehouse management, etc.
The enterprise automation system software modules may be run on respective computer systems, the computer systems being interconnected by connecting interfaces such as internet connections, Virtual Private Network (VPN) connections, company internal data network connections, leased data lines, etc. The enterprise automation system may further comprise a technical management application configured for performing an overall management of the enterprise automation system software modules of the enterprise automation system, which may provide for a centralization of the management of the software modules and associated business processes.
Tasks to be performed by the technical management application may comprise: Solution Implementation and Template Management, Solution Documentation, Functional Test Management, Change Control Management, IT Service Management, Technical Operations, Business Process Operation, Maintenance Management, Upgrade Management, and Custom Code Management.
Generally, the enterprise automation systems are configured in accordance with a business process or other organisational process of an organisation. As a result, the enterprise automation systems may largely vary in terms of types and composition of software modules as applied, versions and configurations of the software modules, interconnection of the software modules.
In order to retain the enterprise automation system safe, vulnerability assessments are commonly performed, in order to assess vulnerabilities, such as vulnerabilities to intrusions, viruses or other malware.
Each enterprise automation system software module may be configured in accordance with a client’s requirements(i.e. the requirements of the enterprise), so as to meet requirements of the business process of the client. Such customisation may be performed in may ways, e.g. by providing the software module with sub-modules performing specific functions, by means of settings, customized add-ons, etc., as desired to meet the client’s requirements. Also, a variety of versions/releases of a software module may be applied in the market at a time, the use of a particular release depending on configuration, customisation, client release update scenario, etc. Similarly, each interface may be different in accordance with a client’s data network infrastructure and physical distances between various business establishments.
Given the large variety of configurations of the enterprise automation systems, and given that vulnerabilities tend to largely differ between various enterprise automation system software modules and their versions, the interconnection interface types between the enterprise automation system software modules, as well as various other factors, an assessment of vulnerabilities is generally highly labour intensive and performed per component of the enterprise automation system (e.g. per software module, per interface, etc.).
Accordingly, the invention intends to provide an improved vulnerability assessment of an enterprise automation system.
According to an aspect of the invention, there is provided an enterprise automation system comprising a plurality of enterprise automation system software modules, a technical management application configured for performing management of the enterprise automation system software modules, and a vulnerability assessment application configured for assessing the enterprise automation system software modules and the technical management application for an occurrence of vulnerabilities, each of the vulnerabilities forming a potential weakness in a protection of the enterprise automation system, wherein the vulnerability assessment application is provided on top of a software stack of the technical management application.
Generally, a concept applied in virus detection or detection of vulnerabilities in general is to provide a separate software program that performs such tasks. For example, a variety of anti -virus programs are offered on the market, such programs assessing a computer or computer system from the outside, i.e. testing software for viruses without forming part of the software themselves. Such an approach is generally considered as good software engineering practice, as otherwise a virus may more easily attack the anti-virus software itself.
The inventors have however devised that the vulnerability assessment application is provided on top of the software stack of the technical management application. The term software stack is to be understood as a stack of software layers that are applied to operate the technical management application. Generally, a bottom of a software stack represents a lowest software layer, while a top of the software stack represents a highest software layer. The vulnerability assessment application is implemented on top of the software stack of the technical management application. A main principle of a software stack is that each different software layer within the stack supplies services and exposes application programming interfaces (API’s) to the software layer above. In such a configuration, the vulnerability assessment application is able to make use of the API's provided by the technical management application and also the software layers located underneath the technical management application.
The fact that the vulnerability assessment application is provided on top of a software stack of the technical management application enables the application to reuse a large variety of API’s that are native to the enterprise automation system. It enables the vulnerability assessment application to “speak the same language” as the enterprise automation system being examined.
For instance (in the case of for example an SAP system): API’s from the Netweaver stack are used in order to generate the different connection types to the enterprise automation system. Another example is the re-use of many existing remote capable function modules inside the checks that are executed in enterprise automation system the order to determine the presence of a vulnerability. These functions are part of the SAP Netweaver stacks, therefore they also exist in the enterprise automation system and no additional “agent” code needs to be imported. Some functions located in the SAP Solution Manager stack make it possible to check the validity of the software stacks of the enterprise automation system. In addition the vulnerability assessment application itself is based on the ABAP and WebDynpro environment located inside the Netweaver software stack and reuses many API’s, for example the Floorplan Manager for Webdynpro enabling a stable and reliable GUI. Most important of all, the underlying SAP Netweaver stack provides the application with a very reliable, secure and scalable multi-user environment”.
As the vulnerability assessment application is provided on top of the software stack of the technical management application, in an embodiment, the vulnerability assessment application may have access to (part of) configuration data representative of a configuration of the automation system, in particular configuration data of the enterprise automation system software modules and/or the interfaces there between, thereby providing that the vulnerability assessment application may adapt the vulnerability assessment and select applicable checks in accordance with the configuration of the enterprise automation system in question.
Generally, the vulnerability assessment application is able to retrieve the configuration of the automation system, in particular the configuration data of enterprise automation software modules and the technical system context in general. The configuration may be retrieved from the enterprise automation system software modules, e.g. by sending a request for configuration data to the automation system software modules.
The enterprise automation system may be any computer implemented enterprise automation system. In particular, the automation system may be an enterprise automation system which automates a variety of tasks in an enterprise. For example the enterprise automation system may automate tasks such as finance, controlling, materials management, sales and distribution, plant maintenance, production planning, quality management, project planning, human resource planning, workflow management warehouse management, etc. Each of the software modules may perform one of such tasks. The software modules of the enterprise automation system may each in turn each form a computer system programmed to perform one or more of the tasks as mentioned above. The enterprise automation system may hence comprises a plurality of computer systems, each handling a software module. The computer systems of the enterprise automation system being interconnected by respective interfaces so as to enable data communication between them, etc. The vulnerability may be any vulnerability of the enterprise automation system. The term vulnerability is to be understood as a potential weakness in a protection of the enterprise automation system, the weakness against any form of un-authorized access to a part of the enterprise automation system. The vulnerability may be a vulnerability to perform actions related to the enterprise automation system or the data stored therein, without being authorized to do so/ Examples may include unauthorized reading of data or data traffic, (unauthorized) injection of a virus or other malware, unauthorized getting access to login data or circumvent login procedures, unauthorized entering of data or program modules into the system, etc.
In an embodiment, the vulnerability assessment application comprises a set of checks, each check being associated with a respective vulnerability and comprising: - check data, the check data providing information to the vulnerability assessment application in order to assess the respective vulnerability, the vulnerability assessment application being configured to select a subset of the set of checks in accordance with a configuration of the enterprise automation system.
Thus, a subset of checks, e.g. checks applicable in the configuration, are automatically selected by the vulnerability assessment application in accordance with a configuration of the enterprise automation system.
In an embodiment, each check further comprises check configuration data, the check configuration data providing information to the vulnerability assessment application in what configuration of the enterprise automation system the respective check is to be performed, and wherein the vulnerability assessment application is configured to: - retrieve the check configuration data associated with each check, - retrieve a configuration of the enterprise information system - select the check into the subset of checks based on the check configuration data and the configuration retrieved from the enterprise automation system
As the technical management application is configured to retrieve the configuration information of the enterprise automation system, the checks that are to be performed by automatically be selected from a set of possible checks, using the check configuration data . The vulnerability assessment application may hence automatically select the checks that may be relevant to a particular enterprise automation system by matching the check configuration data with the configuration retrieved from the enterprise automation system. The checks may comprise any vulnerability related assessment, such as checking minimum password requirements, verifying data communication encryption settings, etc. Further examples will be provided in this document. The set of checks may form a set of possible checks that may be performed. A vulnerability assessment as performed by the vulnerability assessment application is thus formed by a subset of the checks, the subset of checks having been selected using the configuration retrieved from the enterprise automation system and the check configuration data as explained above.
The vulnerability assessment application may select which ones of the checks to be performed in a particular configuration based on the one hand on a configuration of the enterprise automation system, and on the other hand on the check configuration data of the checks, the check configuration data of a check providing information about the respective check. In general, the check configuration data may comprise information that establishes in what configurations of the enterprise automation system the check is to be performed. Also, configuration dependent check parameters of the check may be provided in the check configuration data. Thus, using the check configuration data, for each check data may be entered that expresses in what circumstances the check is to be performed. The check configuration data may provide filtering information to enable the vulnerability assessment application to filter the checks in order to form the subset of checks. Thus, the vulnerability assessment application may accordingly select a subset of the checks to be executed by it, hence allowing the vulnerability assessment application to perform a vulnerability assessment that suits a configuration of the enterprise automation system in question.
The check configuration data of each check expresses in what circumstances, i.e. in what configurations, the particular check is to be performed. The check configuration data may also comprise values of one or more check parameters, the values of the check parameters being associated to configuration data. For example, a check password length may comprise check configuration data defining a parameter minimum password length, whereby the parameter minimum password length has different values for different configurations The check configuration data may express the configuration in which the check is to be performed in any suitable way. For example the check configuration data may define for what software modules or software module versions the particular check is to be performed. Also, the check configuration data may define for what software module sub components (i.e. sub components of a particular software module) the check is to be performed. Furthermore, the check configuration data may define for what interfaces or type of interfaces the check is to be performed. Still further the check configuration data may define for what combinations (i.e. combinations of software modules, sub modules, interfaces, etc.) the check is to be performed.
In an embodiment, the check configuration data comprises at least one of: - an impact of a vulnerability when detected; - a likelihood of exploitation of the vulnerability;
As the check configuration data comprises information about at least one of impact and likelihood of exploitation, it may be assessed what a consequence of exploitation of a vulnerability may be. In case a vulnerability would be detected by the vulnerability assessment application, an urgency of addressing the vulnerability may be determined based on impact, likelihood of exploitation or both..
In an embodiment, the vulnerability assessment application is configured to - associate an impact value and a likelihood value to each check, and - determine a risk associated with the check from the impact value and likelihood value associated with the check.
The impact value may express a severity of the vulnerability: a high impact may express that the vulnerability, if exploited, could result in a high impact on an operation, data safety or other aspect of the enterprise automation system. The likelihood value may express a likelihood that a particular vulnerability is exploited. For example in the case of a well known vulnerability, the likelihood of exploitation may be relatively large, while in the case of a potential attack which is likely to not have been discovered by an outsider yet, the likelihood may be low. Determining a risk from the impact value and the likelihood value, e.g. by means of weighted sum of impact and likelihood values, may allow to take both these factors into account in a balanced way.
In an embodiment, the vulnerability assessment application is configured to apply respective weight factors to the impact value and the likelihood value, the risk being determined from the impact value and likelihood value as weighted by the respective weight factors. The weight factors may be set by the user of the application. Furthermore, the weight factors may be complementary: when a user provided input to raise one of the weight factors, the other one may correspondingly be reduced so as to provide a convenient and readily comprehensive adjustment by the user. The weight factors may be presented to the user in the form of a displayed slider bar, whereby sliding the slider towards one end increases a weight of impact and sliding the slider towards the other end increases a weight of likelihood,
In an embodiment, the vulnerability assessment application is configured to - associate a mitigation effort value to each check.
The vulnerability assessment application may hence provide information to a user of the vulnerability assessment application or to the technical management application concerning a mitigation effort, i.e. concerning an effort in terms of e.g. cost, down lime, man hours, etc. to solve the vulnerability by a suitable action. The mitigation effort may form part of (i.e. may be comprised in) the check configuration data.
In an embodiment, the vulnerability assessment application is configured to - rank the checks according to their associated mitigation effort, and - present a list of primary actions based on the checks having a lowest associated mitigation effort.
Based on the mitigation effort value, the vulnerability assessment application may assist to establish a mitigation strategy: the checks which resulted a determination of a potential vulnerability may be ranked according to their associated mitigation effort, and a mitigation scenario may start by addressing the checks having the lowest mitigation effort. Thus, steps that may be performed relatively easily (e.g. without a need to take the automation system or parts thereof out of operation in order to perform maintenance or without a need to perform significant hardware upgrades, etc.) may be selected first, so as to be able to address these vulnerabilities in a shortest time frame possible.
In an embodiment, the vulnerability assessment application is configured to - provide references to instructions to a user of the vulnerability assessment application for solving at least part of the vulnerabilities. The instructions as provided by the vulnerability assessment application may comprise references to (e.g. more detailed) further instructions. In an embodiment, the vulnerability assessment application is configured to provide links to instructions aimed at qualified and authorised vulnerability assessment application users for solving at least part of the vulnerabilities.
In an embodiment, the vulnerability assessment application is configured to: - allow users of the vulnerability assessment application to subscribe to reports produced. And - send emails to all subscripted users containing links to the reports that they have subscribed to.
In an embodiment, the vulnerability assessment application is configured to establish a connection to one of the enterprise automation system software modules in order to execute one of the checks via the connection, the connection comprising: - one of an HTTP Hyper Text Transfer Protocol) and RFC (Remote Function Calls) connection in case of the check being at an application layer of the enterprise automation system software module, - an ADBC (ABAP database connectivity) connection in case of the check being at a database layer of the enterprise automation system software module, and - an operating system control connection (e.g. a SAP control connection) in case of the check being at an operating system layer of the enterprise automation system software module.
Using the different connection types, checks can be made more robust. For example, if a connection type does not work or the data retrieved is not consistent, a fail-back connection type may be used in order to execute the Check. For example, to check the existence of a file in an ABAP type SAP system a remote RFC function may be used. Should this not work for some reason, then the same Check may use a SAP control connection as a fallback.
In an embodiment, the vulnerability assessment application is configured to - search for an occurrence of a predefined condition in at least one of the technical management application and the enterprise automation system software modules, and - set a value of at least one of impact, likelihood and mitigation effort associated with a check associated with the predefined condition to a predefined value in case of the occurrence of the predefined condition.
Correspondingly, check attributes of a check (as e.g. set by a user) may be overridden in case of occurrence of predefined conditions e.g. a condition in the system in which the respective attribute (e.g. impact, likelihood and mitigation effort) of the check do not adequately reflect the predefined condition.
For example, a Check on the minimum length of passwords is not so relevant when Single SignOn (SSO) is used within the SAP system, since authentication has already been done in another system and no password is necessary in order to logon. This means in this specific case that password related Checks are academic and the Impact and Likelihood values are lower than when SSO is not active. Thus, seeking for predefined conditions (such as in the above example Single SignOn) and correspondingly adapting attributes (likelihood, risk, mitigation effort, etc.) may provide for more appropriate testing in the case of the occurrence of the predefined condition. The predefined condition may for example be an exception, a high risk situation, or any other situation that a user of the vulnerability assessment application may not have anticipated.
In an embodiment, the automation system is a SAP automation system, wherein at least one of the software modules is an SAP software module, and wherein the technical management application is a SAP solution manager.
The automation system may be an SAP automation system, i.e. an automation system designed by SAP software. As the SAP company automation systems tend to be complex and generally highly configurable to meet a demand of a business, SAP systems tend to show a large variety in terms of configuration, which in the state of the art results in a highly labour intensive and modestly effective vulnerability assessment.
According to a further aspect of the invention, there is provided a method of assessing vulnerabilities in an enterprise automation system, the enterprise automation system comprising a plurality of enterprise automation system software modules, a technical management application configured for performing management of the enterprise automation system software modules, and a vulnerability assessment application configured for assessing vulnerabilities in the enterprise automation system software modules and the technical management application, the method comprising performing a vulnerability assessment by the vulnerability assessment application wherein the vulnerability assessment application is comprised in a software stack of the technical management application.
According to a still further aspect of the invention, there is provided a software program comprising program instructions for, when run on a data processing device, make the data processing device perform the method according to the invention.
With the method and software program according to the invention, the same or similar effects may be achieved as with the automation system according to the invention. Also, the same or similar embodiments may be provided as described with reference to the automation system according to the invention, the embodiments of the method and software program according to the invention may achieve same or similar effects as described with reference to the corresponding embodiment of the automation system according to the invention.
Further features and effects of the invention will be explained based on the enclosed drawing, showing a non-limiting embodiment of the invention, wherein:
Figure 1 depicts a flow diagram of a SAP mitigation cycle;
Figure 2 depicts an overview of application components and API’s in accordance with an embodiment of the invention;
Figure 3 depicts a block schematic view of a system according to an embodiment of the invention;
Figure 4 depicts a security analysis application view in accordance with an embodiment of the invention;
Figure 5 depicts a business objects hierarchy diagram in accordance with an embodiment of the invention;
Figure 6 depicts a 4 exemplary SAP system configurations; and;
Figure 7A and 7B depict risk slider bars in accordance with an embodiment of the invention. The present invention will be explained from an embodiment as applied in a system from the manufacturer SAP (Systems, Applications & Products in Data Processing) which is a German multinational software corporation that makes enterprise software to manage business operations and customer relations. SAP is headquartered in Walldorf, Baden-Württemberg, Germany.
SAP
The company SAP A.G. is a market leader in Enterprise Application Software and presently has more than 253,500 customers in 188 countries. The company sells a wide range of business applications on many different technical platforms. The most critical of these business applications are Enterprise Resource Planning (ERP) systems which are typically used by medium- and large-sized businesses in order to support their business processes, such as Sales & Delivery, Finance, Human Resources, Logistics, Warehousing and Supply Chain Management, etc. SAP Systems contain sensitive company data that should be protected in order to maintain the highest confidentiality, integrity and availability. SAP Security problem
Conventional security measures for SAP systems tend to focus on preventing fraud by means of Segregation Of Duties (SOD). Unfortunately, SOD itself is not capable of stopping hackers since these typically manage to avoid the SAP Authorization mechanism entirely.
By using and exploiting vulnerabilities within the SAP Infrastructure, a hacker may gain access to the data stored inside these systems, and compromise the security of all the systems within the SAP Infrastructure.
In order to prevent security threats, a mitigation cycle needs to be implemented, the following steps of the mitigation cycle being depicted in Figure 1: 1. Identification of vulnerabilities (1) 2. Risk assessment and selection of vulnerabilities to be remedied (2) 3. Creation of Mitigation Plan (3) 4. Implementation of Mitigation Plan (4)
Applying this mitigation cycle to SAP systems is problematic, since: SAP does not currently offer a comprehensive automated solution to find the vulnerabilities within SAP Infrastructures. A manual vulnerability scan requires expensive specialized skills and knowledge.
The SAP Infrastructure consists of various layers (such as: Operating System (OS), Database (DB) and SAP Application) and may be physically implemented by a large variety of different OS-, DB- and SAP system-types and -versions. These all have their own specific vulnerabilities.
Medium and large sized companies may have many SAP systems, making periodic manual checking very time consuming, fault-prone and costly. A classification of vulnerabilities in terms of Risk and Mitigation Effort does not currently exist. SAP customers generally don't have the specialist knowledge and expertise available to identify vulnerabilities and to carry out a Risk assessment.
Solution
The ERP Protect4S Vulnerability and Compliance scanner for SAP, also referred to as the vulnerability assessment application, hereafter called “the scanner” or “the application”, is capable of carrying out a fully automated vulnerability scan of different types of SAP systems on a variety of different Operating Systems and Database systems. During such a scan checks are made in order to detect the vulnerabilities. A single check is executed in order to determine the presence of a specific vulnerability. A risk value will be calculated for each vulnerability found. The result is a detailed report containing the detailed log of the scan. Each check listed in the report will have the following properties:
Property Description
Risk Risk of vulnerability: Very Low, Low, Medium, High and Very High
Impact Impact when exploited: Very Low, Low, Medium, High and Very
High
Likelihood likelihood of exploitation: Very Low, Low, Medium, High and Very High
Mitigation Mitigation effort required: Very Low, Low, Medium, High and Very
Effort High
Vulnerability Description of vulnerability
Solution Advice on how to prevent or mitigate the vulnerability
References Hyperlinks to more SAP™ official information on this vulnerability Details Details on the specific findings of this check
The scanner does not require any specialist knowledge to operate.
The report that is produced is all that is needed to form the basis for a detailed mitigation plan.
The scanner will be continuously updated in terms of content. New checks will be delivered in order to identify new vulnerabilities.
General Characteristics of scanner
The scanner is designed from the view of a SAP system administrator (as opposed to a hacker) and requires authenticated connections to the systems that must be scanned, so-called "satellite systems".
As depicted in Figure 2, a unique characteristic of the scanner is that it is implemented as an Add-On on top of the software stack of a SAP Solution Manager. The SAP Solution Manager is a special SAP system that is used for application lifecycle support of all other types of SAP systems. In this document, the solution manager is also referred to as a technical management application. It re-uses many of the underlying SAP Standard API's, resulting in advanced application features, efficient and robust coding that is easy to maintain.
Figure 3 depicts a highly schematic block diagram of an enterprise automation system in accordance with an embodiment of the invention. The system comprises a plurality of enterprise automation system software modules EASSM (also referred to as “satellite systems”), and a technical management application SMA (also referred to as “solution manager” or solution manager application) configured for performing management of the enterprise automation system software modules. Furthermore the system comprises a vulnerability assessment application VAA configured for assessing the enterprise automation system software modules and the technical management application (i.e. in SAP solutions manager application) for an occurrence of vulnerabilities (schematically indicated in the figure as VUL). Each of the vulnerabilities may form a potential weakness in a protection of the enterprise automation system. As described, the vulnerability assessment application is provided on top of a software stack of the solutions manager application, i.e. in general terms on top of a software stack of the technical management application.
In an embodiment, the vulnerability assessment application VAA comprises a set of checks CHK, each check being associated with a respective vulnerability and comprising check data CHKD, the check data providing information to the vulnerability assessment application in order to assess the respective vulnerability. The check may further comprise check configuration data CHKCD, the check configuration data providing information to the vulnerability assessment application in which specific configurations of the enterprise automation system the check should be executed.
The vulnerability assessment application may hence automatically select the checks that may be relevant to a particular enterprise automation system by matching the check configuration data against the configuration of retrieved from the enterprise automation system.The software stack consists of the 3 main software layers (Figure 2): 1. VAA: the vulnerability assessment application 2. SSM: SAP Solution Manager 3. SNW: SAP Netweaver
The vulnerability assessment application (VAA) comprises the following components: □ APCNF: Application Configuration □ RTCNF: Run-time Configuration □ EXNOT: Execution and Notification □ REPRT: Reporting □ APAUD: Application Auditing
The SAP Solution Manager (SSM) software layer offers the following API's to the vulnerability assessment application: □ SMWC: Solution Manager Workcenters □ OSSINT: OSS Interface
The SAP Netweaver (SNW) software later offers the following API's to the vulnerability assessment application: □ COMSRV: Communication Services o ADBCCON: ADBC database connector (Native SQL Interface) o WEVSRV: Web Services (SOAP) functionality o RFC: Remote Function Call functionality □ JOBSCHED: SAP Job-Scheduling Interface □ UISERV: User Interface services o WEBDYN: Web Dynpro API's
o FPMAN: SAP Floor Plan Manager API o SAPUI5: SAP UI5 Support o FBPINT: Floor Plan BOPF Integration (FBI) o BOBFFW: Business Object Processing Framework □ NWISRV: Netweaver Infrastructure Services o ARCHLNK: Archive Link o CHGDOC: Change Documents o APPLOG: Application Logging
User Interface
The application is built as a SAP WebDynpro Floor Plan Manager Application (FPMAN) and therefore uses the MVC (Model View Controller) architecture in which business logic is separated from the user interface and components are separated from their configuration. In addition the SAPUI5 API (SAPUI5) facilitates genuine HTML5 browser applications and enables the application to run on Mobile clients.
Business Object Layer (BOL)/ Business Object Processing Framework (BOPF)
The Business Object Processing Framework (BOPFFW) provides API's for managing the transactions and the underlying database tables. Native SAP functionality as: Data Archiving (ARCHLNK), Change Documents (CHGDOC) and Application Logging (APPLOG) are part of the application.
Business Objects
The important Business Objects that are used within the application (Figure 4): □ PRJ: Project A Project is a collection of 1 or more Scans that is scheduled to run (periodically) at a certain time or executed on the fly by a user of the application. For example: a Project may group identical Scans that are executed on different Systems or it may group different Scans executed on a single System. □ RUN: Run A Run is a Project that has been executed completely. A Run contains all relevant data about the Scans that have been executed and the Systems that have been scanned. Since the technical System context may vary over time, this context is copied during each Scan into the Run-related data. In this way the technical context, such as the exact System component versions, SAP kernel version (of each instance) and database version at the time of the Run is preserved and can still be examined at a much later time. □ SYST: System
Describes the SAP system that is scanned, and has properties as: SAP System ID, SAP Installation Number, a reference to the Company that owns the system, SAP System Type (ABAP, J2EE, Double Stack), and System Role (Sandbox, Development Acceptance, Production). □ COMP: Company
Describes the Company that owns the SAP system and has properties as: Company name, Company address, Company website. □ CONN: Connections
Contains the connection properties that the Solution Manager needs in order to connect to a given System. Provided that all access data is correctly provided, connections will be created to the different application components and to every client of the System. □ SCAN: Scan A Scan defines: - which System will be scanned - which Checks will be run - which notifications will be sent to which Contacts at which time.
Each Scan checks a single SAP system. □ CHK: Check A Check is a test for determining the presence of a specific, single vulnerability. An example of a Check is a test for the existence of a given Access Control List (ACL). If the ACL file exists, the Check has passed and if the file does not exist, the Check has failed. A Check may have a Check-Value, which is a threshold value or a value range in combination with an operator. An example of this is a Check on the value of SAP System parameter login/min_password_lng.
For Check-Value 10 and operator ">=" (greater-than or equal), the Check will fail if the actual value of the parameter is less than 10 characters (which implies that the SAP system accepts passwords shorter than 10 characters) and it will pass when the value of the parameter is equal to 10 or higher. A failed Check means that a vulnerability has been detected.
Checks are grouped into groups and sub-groups. An example of a group is the group called “Authentication” that contains sub-group “General Logon”. □ TM PL: Check Template A collection of Checks may be grouped into a Check Template. A Check Template may be delivered with the application as a non-changeable template that conforms to a security standard or policy, for example Sox, PCI or Bizec.
Check Templates may also be created by the user. In that case the user selects the Checks that are relevant to, for example, a Company security policy and groups these Checks into a new Check Template. This Check Template may then be used in Scans on different Systems.
Check Templates may be copied and adapted by users. Users may remove or add new Checks to their copied template and alter the Check-Values of Checks. □ CONT: Contact
Describes the security and compliance staff members that may subscribe to notifications from the application whenever a scan has finished. These persons must be authorized in order to be able to read the reports produced by the application. Contact properties are: first name, last name, SAP user name, telephone number(s) and email address.
Application Components
The application consists of 5 main parts (see figure 5): 1. APCNF: Application configuration : Initial setup and configuration 2. RTCNF: Runtime configuration : Definition and scheduling of Projects 3. EXNOT: Execution : Project/Scan execution 4. REPRT: Reporting : Showing the results of a Scan 5. APAUD: Application Auditing : Shows changes to application objects 1. Application configuration (APCNF)
In order to enable the application to run, the System (SYST) and associated Connections (CONN), Company (COMP) and Contacts (CONT) data will have to be created first. Typically one would start with creating the Companies because these are referenced by the System objects.
During the creation of the System object, a wizard (CONNWZ) is used in order to create the Connections that belong to it. The user is guided through a sequence of input screens in which the required user ID’s and passwords must be supplied. Provided that data is correct, the SAP hostcontrol connection, RFC connection and ADBC database connection types will be generated. SAP Systems have many different forms, depending on their system type, -version and size. The modern SAP systems from version 740 onwards all consist of 6 elementary components that may be located on different (virtual) hosts. These components are:
Component Tier Function PAS Application Logic Primary application server. Is always installed as the first SAP Instance inside the Application logic tier. AAS Application Logic Additional application server that may be installed in order as a method of scaling out system capacity. SCS Central services JAVA Central Services. Controls the lock administration and communication between SAP JAVA instances. ASCS Central services ABAP Central Services. Controls the lock administration and communication between SAP ABAP instances. ERS Enque Replication (for High Availability systems only). Replicates the central lock table to a standby enque process. DB Database Stores and retrieves application data and may contain ABAP or JAVA schema’s (or both) that store application related data in tables.
Figure 6 shows different SAP system layouts : 6A: ABAP System 6B: J2EE System 6C: Simple Double Stack System 6D: Complex Double Stack System
The art of the connection wizzard lies in the fact that it simplifies the process of providing the data needed for creating the System connections by minimizing the amount of data required from the end-user and using automatic discovery of the system layout.
In Application configuration: - New Check Templates (TMPL) may be created by: - selection of individual Checks - adaptation (copy and change) of existing Check Templates - Check templates that are delivered by ERP Security as part of the application cannot be changed.
When System and associated Connections, Company and Contacts data have been created, the application is ready for use.
The Application configuration menu may always be accessed in order to change and update the objects that were created previously. 2. Run time configuration (RTCNF)
Once the initial application setup has been done, the runtime configuration phase may start. During this phase new Projects (PRJ) may be defined using the Project Wizzard (PRJWZ). After creating the Project description, the user is able to create the Scans that will be run during the execution of the Project. Each individual Scan is a combination of: - a System - a collection of Checks
After selecting the System that will be scanned, the user has to select the Checks required by either: - selecting an existing Check Template: no changes in Check-Values (CHKV) possible - selection of individual Checks: changes in Check Values possible - adaptation (copy and change) of existing Check Template: changes in Check Values possible.
The Checks that contain Check-Values (CHKV or variable thresholds), may be changed. Normally these Checks will contain a default and best-practice threshold Check-Value, but the user may choose to Check against values that are in line with the specific security policy of the System owner. In that case the user will change the Check-Value belonging to that Check.
Finally the user must schedule the Project for execution. The SAP native Job-scheduler (SCHED) is used to schedule the Project in the form of a SAP background job. This execution may be periodically repeated. It is also possible to execute the Project immediately. 3. Execution and Notification (EXNOT)
When the scheduled time has been reached, the SAP job scheduler (SCHD) will start up a single background job that runs a Project engine (PRJENG) that in turn launches the different Scans in parallel in different dialog work processes.
As a first step, the System’s Connections are checked and when these are ok, the System context (SCNTXT) is determined first. The System context consists of: - a list of all SAP instances and the services offered - a list of all SAP network access points per instance host containing port numbers and protocols - a complete version specification of all SAP components, SAP kernel, database and operating system - a complete list of all relevant SAP parameters
Using the System context, the Scan will only run the selected checks that are suited for the System. It is the Check Filter (CHKF) task to select only those Checks that match the System context.
This System context (SCNTXT) will be stored in memory during the duration of the Scan. For reasons of efficiency, many of the Checks will be executed against this System context.
After completion, relevant parts of the System context will be compressed and stored in the database as part of the Run information. In this way, even if the system context of the satellite system has changed over time, it will still be possible for a user to see what the relevant System properties were at the time of the Scan.
After the System context has been established, the Scans will be started. Whenever a Check cannot be executed, for instance due to technical reasons, an exception takes places and an error message will be logged for that particular Check. This will however not stop the other checks in the same Scan.
The execution of the different Scans within the project will be done in parallel. The degree of parallelism depends on the amount of work processes available in the Solution manager. Provision has been made not to overload the available RFC resources.
Notification and subscription
At any given time, a user may subscribe to different Scans. A deamon program (NOTD) runs periodically and sends an email (NOTFY) to all subscripted users containing links to the Scan reports that they have subscribed to.
In order to view such a Scan report, the user must be authenticated by the application and have the appropriate authorizations. 4. Reporting (REPRT)
It is always possible for a user to display the results of Scans that have been executed previously. Scans may be selected using (combinations of) many different properties, such as : Run ID, Project ID, Run date, Run time, Project description, Scan ID, Scan description, Run status, System ID, System description, SAP System ID, System type, System Role, Company ID, Company name, Check Template ID and Check Template description. Combinations of these properties may also be used in order to produce, for example, a list of Scans executed on the SAP Production type Systems of a particular Company.
The Scan report (REPT) shows: - Information about the Project, System, Scan, the Company and the Check template that was used - The complete System context at the time of the Run. - Scan Statistics consisting of average CVSS Score and Risk of the failed Checks - Risk distribution heat map (Impact vs. Likelihood) - Mitigation Effort heat map (Risk vs. Mitigation Effort) - An overview of all Checks that have been executed within that Scan.
Each record in that list shows: - the result of the Check (Fail, Pass) - the Check name - the Check description - the calculated Risk value - the Impact value - the Likelihood value - the Mitigation Effort - the CVSS Score - the run status (whether the Check aborted or not)
If a Check is Instance- or Client dependent, then its Risk value equals the maximum Risk value encountered in each Instance or Client.
Each failed Check in the Scan overview list represents a vulnerability. A filter makes it possible to view either: all Checks executed, all Checks that have Passed or only the Checks that have failed.
For each Check executed, it is possible to jump to a detail screen that displays: - the messages generated for that particular Check - whether the Check is Instance-dependent - whether the Check is Client-dependent - a longer description of the Check - (when applicable) the Check-Value that has been used - a description of the vulnerability that was checked - a description of the solution recommended by SAP (or best-practice) - a table containing hyperlinks to SAP documentation, OSS Notes or SAP help pages
The complete list (including the Check details) may be exported to a PDF type file. A simplified version of this report is available for mobile devices (UI5REPT). 5. Application Auditing (APAUD)
Special care has been taken to make the application auditable. Whenever a user makes a change is made to an object, it will be recorded in a change document (CHGDOC) that contains: - the date and time stamp - which user executed the change - the object field that was changed - the old value of that field - the new value of that field
The application may be used by (external) auditors in order to provide a sign-off on a particular technical security standard. But, since the application could be used by trusted insiders to gather information about the security of the SAP systems, it is necessary that a complete audit trail of the changes to all application objects is kept. This audit trail may be inspected by the (external) auditor.
Application authorizations/user types
Different user authorizations are needed for accessing the application parts:
Application part Typical user type
Application configuration a senior security officer or security architect Runtime configuration security or compliance officers
Execution and notification application execution by application background user in satellite system
Reporting Chief Information Officer, security or compliance officers, (external) auditors
Application Auditing (external) auditors
Application Internals
Impact and likelihood levels
Each Check aims to determine the presence of a specific vulnerability. In the Scan overview these Checks are presented with the attributes impact and likelihood:
Impact : the impact that a successful exploitation of that vulnerability will have on the business
Likelihood : the likelihood of such a successful exploitation taking place
Both of these properties have the same set of possible values: Very Low, Low, Medium,
High and Very High.
Check attribute override during Check execution
If a Check fails, a vulnerability has been detected. This vulnerability is associated with an Impact and Likelihood value. But in some cases this value needs to be adapted.
For instance, a Check on the minimum length of passwords is not so relevant when Single Sign-On (SSO) is used within the SAP system, since authentication has already been done in another system and no password is necessary in order to logon. This means in this specific case that password related Checks are academic and the Impact and Likelihood values are lower than when SSO is not active.
In order to adapt the values for Impact and Likelihood, additional application logic must be inserted. The application has 2 program “hooks” build-in: one hook just before the Check takes place and another just after a Check has been executed. In the case of SSO, extra code may be inserted after the Check in order to determine whether SSO is used and, if that is the case, to “override” the default values for Impact and Likelihood that eventually will result in a realistic Risk value.
In this example only the default values for Impact and Likelihood were changed, but in fact the value of any Check related attribute (Mitigation effort etc.) may be revised by additional application logic during Check execution.
Risk Calculation
Both impact and likelihood determine the Risk value. Their values are first “translated” to numbers: Very Low = 1, Low = 2, Medium = 3, High = 4 and Very High = 5.
The flowing formula is used to calculate the Risk value:
(The Excel function ROUNDDOWN is used in this equation). The weight factor w has a default value of: 0.5 but may vary between 0 and 1. In this way, the Risk value may depend on what the user find more important: the Impact of a successful exploit or the Likelihood that a successful exploit will occur.
This varying of the weight factor w is realized by a slider element in the Scan overview report. When the slider position changes, the weight value w changes too as will the calculated Risk value. Since the Scan results are sorted on Risk in a descending order, the order of the list will change, pushing those type of vulnerabilities upwards that the user finds more important.
When the weight factor equals 0.5, the Risk can be read from the following table:
Impact Likelihood Risk (1)Very Low (1)Very Low (1)Very Low (1)Very Low (2) Low (1)Very Low (1)Very Low (3) Medium (2) Low (1)Very Low (4) High (2) Low (1) Very Low (5) Very High (3) Medium (2) Low (1)Very Low (1)Very Low (2) Low (2) Low (2) Low (2) Low (3) Medium (2) Low (2) Low (4) High (3) Medium (2) Low (5) Very High (3) Medium (3) Medium (1)Very Low (2) Low (3) Medium (2) Low (2) Low (3) Medium (3) Medium (3) Medium (3) Medium (4) High (3) Medium (3) Medium (5) Very High (4) High (4) High (1)Very Low (2) Low (4) High (2) Low (3) Medium (4) High (3) Medium (3) Medium (4) High (4) High (4) High (4) High (5) Very High (4) High (5) Very High (1)Very Low (3) Medium (5) Very High (2) Low (3) Medium (5) Very High (3) Medium (4) High (5) Very High (4) High (4) High (5) Very High (5) Very High (5) Very High
Aggregate calculation
For each Scan executed, 2 aggregated values will be calculated: 1. Average CVSS score: the average CVSS value of all failed Checks 2. Average Risk score: the average Risk score (where weight factor w=0.5) of all failed Checks
Mitigation Effort definition
Each Check has, in addition to Impact and Likelihood, also a Mitigation Effort (ME) value assigned to it: Very Low (1), Low (2), Medium (3), High (4) and Very High (5). The Mitigation Effort expresses the amount of effort and time needed to mitigate the vulnerability that is checked.
Value Indication* of time needed Examples of mitigation Effort (1) Very Low 5 minutes Dynamic SAP profile parameter Change (2) Low 30 minutes (Very Low +) Static parameter Change and System restart required (3) Medium 2 hours (Low +) Kernel upgrade (4) High 8 hours (Medium +) Support Package / DB / OS Upgrade (5) Very High Several weeks (High +) Change in protocols / architecture or New
Components / 3rd party products required *This is the actual net time needed (excluding Change Management procedures) for an experienced Technical consultant to complete the change(s)
The Mitigation Effort value makes it possible to create a “Quick win” list by identifying the vulnerabilities with the highest Risk and the lowest Mitigation Effort.
Check selection during runtime
Although the application user that schedules the Projects is able to select the Checks that will be executed within all Scans of that Project, in the end only those Checks that are suited to run inside the selected satellite System will actually run. The properties of the Check will have to match the properties of the selected System: OS type, OS version, database type and -version. The operating system type and version type will be filtered during execution time, because a given SAP system may have different instances running on different operating systems.
In addition, the execution of a Check may be dependent on the System Type (ABAP, J2EE) or on the presence of an Instance property, for instance whether or not the Instance contains a: SAP Gateway, Message server, Enqueue server, ABAP Dialog processes, J2EE server nodes, Internet Connection Manager or Internet Graphics server.
Lastly, the execution of a Check may depend on the value of certain System properties.
For instance: a Check (that determines a specific vulnerability) may only be relevant for SAP Systems with a specific SAP main version. If the target System has another SAP main version, then the Check is not executed.
Out of all the Checks selected by the user, the Project engine will select and run only the subset of Checks that are relevant to the satellite System.
Check implementation SAP system types may run on a variety of different databases and operating systems. A database Check that aims to determine the presence of a generic database vulnerability must therefore have different implementations each one suited for a different database type. Although the database interface used is a generic SAP Standard (ADBC), the objects that are queried by means of SQL vary among the different database types.
This is also the case for operating system Checks; on a Windows system different commands must be used than on a UNIX type system. In addition there are many UNIX varieties that support SAP systems. On all of these one may need to use different commands and switches in order to determine the presence of the same vulnerability.
Mobile usage of the application
Although the application was first written for the SAP Solution Manager and can be accessed by a browser connected to that Solution Manager, it will also be ported to mobile devices. The SAP Netweaver stack that is the foundation of the SAP Solution Manager also includes the SAP Netweaver Gateway which makes it possible to expose the business objects defined in the Business Object Processing Framework (BOBF) as an Open Data Protocol (ODATA) service.
After creation of the ODATA service, the SAPUI5 user interface must be created consisting of HTML pages including Javascript. The ODATA data model will be linked to the Ul controls.
Basically the Ul part of the Webdynpro application is rewritten in Javascript in order to achieve the full functionality on a mobile device.
Special Application features
Slider element for adjusting Impact/Likelihood weight factor w The formula for calculation of the Risk value was given as:
The factor w is used as a weight that can be used to control the amount of emphasis that is given to likelihood or impact. A user may decide that the impact of the successful exploitation of a vulnerabilities is more important to them than the likelihood of those vulnerabilities occurring and actually control the value of the weight factor w.
In the application, the variable weight factor is implemented as a slider element and the user may drag the slider to the left and right changing the value of weight factor w to one of the following discrete values: - Impact 1 and Likelihood 0 - Impact 0,75 and Likelihood 0,25 - Impact 0,5 and Likelihood 0,5 (the default) - Impact 0,25 and Likelihood 0,75 - Impact 0 and Likelihood 1 A example of a slider bar set at a weight value of 0,5 is depicted in Figure 7A. In both Figure 7A and 7B, IMP equals "Impact" and LHD equals "Likelihood".
The standard weight value equals 0,5 which means that both Impact and Likelihood have equal importance with regards to Risk. Normally, the vulnerabilities are displayed in a sorted order with the Risk value sorted downwards:
When the slider is adjusted to favour the Impact, the Risk values are recalculated and the resulting list will be sorted differently. An example of a slider bar adjusted to a weight value below 0,5 is depicted in Figure 7B.
System Connection types
The connection wizzard will create 4 different types of connections for a newly defined SAP System: a) RFC Connections Type 3
These connections are used to connect the application to an ABAP type Instance. Using SAP ‘s RFC (Remote Function calls), the application may execute code remotely in a remote SAP ABAP Instance belonging to another system. An SAP System may have been divided by different clients that service different financial and organizational entities like company divisions. Each client may support a separate organization and may have its own set of users. The application will try to create a separate RFC connection to each client of the SAP system.
b) A RFC connection type G A type G RFC connection are typically used to execute HTTP GET statements. The application will create a single connection of this type in SAP JAVA type systems which is used for discovery of the technical system context. c) HTTP Proxy connection HTTP Proxy are used to call WSDL type webservices. The SAP Hostagent offers an interface that makes it possible to execute operating system commands. These may be used by the application to inspect the operating system context of a SAP instance, for instance to detect the presence of certain Access Control Files, to check the permissions on some SAP system files or to check the processes running on the remote server. d) ADBC (ABAP database Connectivity) connection
This connection type connects directly to the database schema and makes it possible to execute SQL statements directly on the database level. The application uses this connection to examine the existence of standard database users and passwords, for example.
The amount and type of connections that will be created to connect a single SAP system to the application therefore depend on: the number of clients inside the ABAP system, the number of different PAS or AAS Instances, the number of different Hosts, the number of database schema’s used in the SAP system.
The main advantages of using different connection types are: - Checks can be made more robust. If a connection type does not work or the data retrieved is not consistent, a fail-back connection type may be used in order to execute the Check. Example, to check the existence of a file in an ABAP type SAP system a remote RFC function may be used. Should this not work for some reason, then the same Check may use a SAP control connection as a fallback. - the different tiers (operating system, database and application) of a SAP System can be checked using: □ a SAP Control connection to execute Checks on operating system level □ an ADBC connection to execute Checks on the database level □ a HTTP connection to execute Checks using Web services □ a RFC connection to execute Checks on application level. □
Implementation details
The vulnerability assessment application as described above may provide the following: - The application is delivered as an AddOn as of version 7.1 of the Solution Manager Platform in combination with a SAP Netweaver 7.02 stack. Therefore, no additional investments in extra hardware are needed. - The application is programmed as a SAP WebDynpro Floorplan Manager (FPM) Application based on SAP™ Business Object Processing Framework (BOBF) and is extremely stable and robust. - The application is developed in the standard SAP Webdynpro User Interface, which is instantly recognizable for SAP end-users and therefore has a low learning curve. - The reports are based on SAPUI5 (HTML5) which makes them readable on a range of different user devices such as: PC, Laptop, Tablets, and Mobile. - The application does not require any coding to be implemented in the SAP™ systems that are inspected. The application framework is agentless and does not introduce new security vulnerabilities. - It is developed on the SAP Netweaver Stack which implies that good performance and scalability are guaranteed. - Big data generated by the application is of no concern, since the SAP Solution Manager also runs on the SAP HANA database, which is extremely suited for this. - The application is able to scan the System that it runs on, something that external SAP Scanners are not able to do. - The application is built on top of the SAP Netweaver stack and re-uses many standard SAP software entities and functionality. It is therefore less sensitive to changes in the underlying Netweaver stack. Many SAP standard Function Modules are used within the checks, for instance. - The application uses different kinds of connections to the SAP Solution Manager Satellite systems and is able to call: o ASAP functions via SAP RFC or HTTP(S) o SAP functions via SAP HTTP(S) proxies o Native SQL via SAP ABAP Database Connectivity (ADBC) interface o SAP Hostagent functions via HTTP(S) proxies o OS programs via SAP Hostagent - The application is essentially “white-box” and requires a connection setup. - Apart from these source system connections, the application does not need any information regarding the systems to be scanned. Instead it will discover the system setup and execute only those checks that are relevant to the detected technical infrastructure. - The application is capable of executing scans on multiple systems simultaneously. Multiple Scans against a different SAP systems may be defined in a single Project that can be (repeatedly) scheduled for later execution. - By nature, the application is multi user environment and can handle simultaneous users and user types that execute different application parts at the same time. - The application is delivered on a Unicode platform in English initially. Future delivery of the application in other languages is possible because: o the standard SAP™ translation tools can be used for this. o the SAP Solution Manager is a Unicode type system that supports the use of many languages. - The application lifecycle depends on that of the underlying SAP Solution Manager platform: o New Installation versions must be made available when a new major SAP Solution Manager Version is launched. o An upgrade path must be provided to upgrade an old version of the application to a new version suitable for a new version of the SAP Solution Manager platform. o Support for old application versions must stop when SAP Solution Manager support ends. - The application itself is secured: o it requires different user authorizations for each application part o it keeps an audit log of changes made to every application object o inspection of this audit log requires special permissions o links to Scan reports can only be opened by authorized users
Claims (25)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NL2014909A NL2014909B1 (en) | 2015-06-03 | 2015-06-03 | Enterprise automation system vulnerability assessment. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NL2014909A NL2014909B1 (en) | 2015-06-03 | 2015-06-03 | Enterprise automation system vulnerability assessment. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| NL2014909A NL2014909A (en) | 2016-12-12 |
| NL2014909B1 true NL2014909B1 (en) | 2017-01-31 |
Family
ID=53836159
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| NL2014909A NL2014909B1 (en) | 2015-06-03 | 2015-06-03 | Enterprise automation system vulnerability assessment. |
Country Status (1)
| Country | Link |
|---|---|
| NL (1) | NL2014909B1 (en) |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8726393B2 (en) * | 2012-04-23 | 2014-05-13 | Abb Technology Ag | Cyber security analyzer |
| US20140137257A1 (en) * | 2012-11-12 | 2014-05-15 | Board Of Regents, The University Of Texas System | System, Method and Apparatus for Assessing a Risk of One or More Assets Within an Operational Technology Infrastructure |
-
2015
- 2015-06-03 NL NL2014909A patent/NL2014909B1/en not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| NL2014909A (en) | 2016-12-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11627054B1 (en) | Methods and systems to manage data objects in a cloud computing environment | |
| US20210334821A1 (en) | Platform for facilitating an automated it audit | |
| US20220342846A1 (en) | Efficient configuration compliance verification of resources in a target environment of a computing system | |
| US9253202B2 (en) | IT vulnerability management system | |
| US10812502B2 (en) | Network device owner identification and communication triggering system | |
| Paule et al. | Vulnerabilities in continuous delivery pipelines? a case study | |
| Rahman et al. | Security misconfigurations in open source kubernetes manifests: An empirical study | |
| Bachmann et al. | Developing secure software: A holistic approach to security testing | |
| Jenkins et al. | “Anyone Else Seeing this Error?”: Community, System Administrators, and Patch Information | |
| Gu et al. | Continuous intrusion: Characterizing the security of continuous integration services | |
| Buecker et al. | IT Security Compliance Management Design Guide with IBM Tivoli Security Information and Event Manager | |
| Chandramouli | Implementation of DevSecOps for a Microservices-based Application with Service Mesh | |
| NL2014909B1 (en) | Enterprise automation system vulnerability assessment. | |
| Mangla | Securing CI/CD Pipeline: Automating the detection of misconfigurations and integrating security tools | |
| Haber et al. | Mitigation Strategies | |
| Chhillar et al. | Proposed T-Model to cover 4S quality metrics based on empirical study of root cause of software failures | |
| Chatterjee et al. | Security in DevOps and Automation | |
| Hellström et al. | A Lightweight Secure Development Process for Developers | |
| Spendolini | Expert Oracle Application Express Security | |
| Yadav et al. | A Comprehensive Survey of IoT-Based Cloud Computing Cyber Security | |
| US11822916B2 (en) | Correlation engine for detecting security vulnerabilities in continuous integration/continuous delivery pipelines | |
| Pidlubnyi | Increasing Security and reducing risks running services in a potential containerized environment while meeting regulatory standards | |
| Thompson et al. | Vulnerability management | |
| Chauhan | QUANTIFYING SECURITY IN PLATFORM AS A SERVICE USING MEAN FAILURE COST: A STAKEHOLDER’S PERSPECTIVE | |
| Goel et al. | Analyzing and Mitigating Security Risks in Cloud Computing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MM | Lapsed because of non-payment of the annual fee |
Effective date: 20220701 |