IDC Government Procurement Device Security Index 2018h20195. · IDC’s Government Procurement...
Transcript of IDC Government Procurement Device Security Index 2018h20195. · IDC’s Government Procurement...
COPYRIGHT IDC © 2018 | PAGE 1
Andrew MuntonDuncan Brown Frank Dickson Chris Pennell
May 2018
IDC Government Procurement Device Security Index 2018:
Public Sector PC & Printer RfPs Lack Basic Security Consideration
Sponsored by HP Inc
COPYRIGHT IDC © 2018 | PAGE 2
EXECUTIVE SUMMARY The purpose of this study is to determine the consideration given to security
requirements in public sector procurement of PCs and printers (and print services). The
hypothesis is that although governments claim that security requirements are high on
the agenda, this does not translate to the day to day operations of the procurement
of endpoint devices.
Based on the assessment of 130 requests for proposals (RFPs) in nine countries, the
hypothesis was validated. Overall, weak consideration is given to security requirements
within public sector procurement of both PCs and printers. Procurement processes
within the public sector do not reflect current, modern security capabilities, nor do
they account for the emerging types of threats that undermine traditional security
approaches (such as malware functioning below the operating system). Almost one-third
(29%) of the examined RFPs have no consideration of security at all.
IDC’s Government Procurement Device Security Index, compiled across the nine
countries, shows similar patterns of poor security consideration. Although differences
exist between countries, no country scored well. A few RFPs demonstrate good security
consideration of PCs and printers, but this good practice is rare. Applying good practice
more broadly could increase the index score of countries considerably, and quickly,
but the inconsistencies between RFPs are wide. Similarly, there are no high-scoring
subsectors within the public sector.
PC and printer procurement professionals may regard these devices as commodities
with the intent that security capabilities are installed on the base equipment through the
deployment of security software, controls, and peripherals. However, if this is indeed true,
we would expect to see higher security consideration in printers, which cannot be easily
enhanced through security add-ons (e.g., antivirus scanning tools, hardware tokens),
than in PCs. In fact, the opposite is true: Printers are subjected to even less security
consideration than PCs.
COPYRIGHT IDC © 2018 | PAGE 3
IDC concludes that public sector procurement of PCs and printers is insufficiently explicit
in the consideration of security requirements. This lack of attention exposes government
agencies to unnecessary risk from modern attack vectors as well as from poor adherence
to security basics. Increased risk applies whether the procured device is a PC or a printer:
Many important modern security capabilities cannot be bolted on after the fact or
provided by a third party. This difficulty in enhancing security is most true for printers but
is also very important in PCs because of the amount of firmware and embedded system
code that now presents a target for attackers. It is important to note that this analysis
does not make judgments as to the appropriateness or completeness of the security
requirements specified. It is possible that a detailed requirement specification mandates
security features that do not serve the purposes for which the device is being procured.
This could be either an under-specification or an over-specification. The point of the
analysis is to examine the detail with which requirements are specified. A more detailed
specification may reflect a well-considered security assessment of needs, but this is
indeterminable from our analysis of RFPs.
COPYRIGHT IDC © 2018 | PAGE 4
SECURITY SITUATION OVERVIEWA dynamic threat landscape pervades society, making our IT systems vulnerable to an
ever-increasing and ever-changing set of security attacks. Governments’ response to this
situation is generally to create national (cyber) security strategies, to develop national
standards, and to increase overall awareness about the nature and severity of the threat.
But at the same time, government departments, especially those with civilian remits and
those far from central government influence, are often unaware of specific vulnerabilities.
Frequently purchased equipment, such as PCs and printers, is regarded as a commodity.
By deeming devices commodities, procurement hopes to leverage an open bidding
process, allowing for free market competition across multiple vendors, and achieve an
optimal price (controlling device cost). If extra security features are required, they can
be procured and retrofitted at a later stage. Unfortunately, this approach exposes public
sector bodies to security vulnerabilities.
Printers are rarely considered a security vulnerability because the legacy view of safety
behind a fortified network perimeter still permeates conventional thought, though
today’s cyber-reality invalidates the view. Printers are often left wide open to all network
protocols and unprotected by passwords. Those that are password protected will often
have the password easily available in plain text. Printers are rarely patched — their
whereabouts often unknown — and are invisible to asset management tools. Yet they
present a substantial security risk: Most printers have broad access to an internal network.
An attacker who compromises a printer can have unfettered access to an organization’s
network, application, and data assets.
PCs are a key attack vector for the cyberattacker. These ubiquitous devices are essential
for the operation of governments the world over, and their ubiquity is thus used against
public sector entities. An entire endpoint protection industry has grown up around
protecting PCs, as well as a plethora of services, and around network monitoring and
identity management capabilities. The vast majority of these protection features assume
that the device itself is trusted but that its behavior is compromised through the
multitude of malicious attacks including, but certainly not limited to, malware, exploits, or
compromised credentials.
COPYRIGHT IDC © 2018 | PAGE 5
Let’s use malware as an illustrative example. Malware is malicious software that looks
to compromise legitimate devices or applications. Malware resides atop the operating
system (OS) and may interact with, change, or exploit vulnerabilities in that OS.
Antimalware solutions are also installed above the OS and check for known malware
signatures and/or abnormal behavior or activity.
But what if the malware compromises the integrity of the OS itself? What if the malware
affects the BIOS, meaning that the PC is compromised as soon as it is switched on? No
antimalware would become aware of a compromise because it looks for malware in the
OS and above. PCs can be shipped with BIOS protections and industry-standard secure
boot mechanisms to help mitigate against BIOS-level malware attacks. But state-of-the-
art techniques go further to not only protect against BIOS-level malware but also detect
if something is wrong and automatically correct it.
COPYRIGHT IDC © 2018 | PAGE 6
BACKGROUND AND RESEARCH HYPOTHESISThe hypothesis for this project is that PCs and printers are considered by government
procurement authorities to be commodity items. Little consideration is given to security
in the procurement of these devices, which is reflected in the RFPs.
The foundational strength of our compute platforms is critical as the rate of growth
in the types and instances of cyberthreats continues to rise. In addition, these threats
increasingly challenge basic features commonly found in undifferentiated PCs and
printers. Threats now operate below the operating system and are thus invisible to
most antimalware programs. This situation leads to current defensive approaches being
undermined.
At the same time, the cyberthreat to governments has never been so high and the
regulatory consequences of a security breach are escalating with the introduction of the
General Data Protection Regulation (GDPR), which has global reach and applicability.
Brief description of approach and methodologyThe hypothesis was tested by analyzing government RFPs and tenders relating to the
procurement of PCs and/or printers (and related services) from nine countries across
Europe and North America, plus Australia. The aim was to identify the level of security
required in these RFPs and score the RFPs relative to our predetermined security schema.
Selection CriteriaA target of 15–20 RFPs per country was set, with consideration made for the size of the
country. The establishment of framework contracts was also a factor in determining
the number of available RFPs to analyze. RFPs from the following countries were
analyzed: Estonia, France, Germany, Italy, Spain, United Kingdom, Canada, United States,
and Australia.
COPYRIGHT IDC © 2018 | PAGE 7
RFPs and/or tenders were considered for analysis where they focused on PCs (laptops,
desktops, 2-in-1s, tablets, and convertibles), printers, and managed print services. RFPs
dating from 2014 to the present were analyzed; however, in cases when a country
implemented mandated framework agreements, RFPs issued prior to these frameworks
were not analyzed.
A focus was placed on federal/central governments and larger local and/or municipal
government organizations. The value of RFPs was typically correlated to the contract size,
ranging from $500,000 upward. We analyzed both specific RFPs and frameworks relating
to PCs and/or printers. RFPs were from public procurement databases. Noncompetitive
or closed procurements and those involving national security and/or classified
requirements were excluded.
Process for EvaluationPotential qualifying documents were acquired. An assessment of language was made to
allocate appropriate native language–speaking analysts. The selection of RFPs introduced
the possibility of bias due to selection criteria, monetary value of the contract, and
other specific circumstances relating to each possible RFP. These potential biases are
acknowledged and addressed wherever possible.
A limited number of sample documents were gathered to help shape and validate the
overall selection criteria and scoring methodology for RFPs. The scoring methodology to
assess each of the relevant RFPs was then validated. The scoring methodology was used
to assess further RFPs in each country. Each RFP was reviewed for scope deficiencies, bias,
and overall general weaknesses, and where appropriate, a replacement RFP was sourced.
All RFP analysis was conducted by native language analysts, generally located in the
country of interest. Results were subsequently reviewed and vetted by global security
analysts to ensure consistency across regions
COPYRIGHT IDC © 2018 | PAGE 8
Approach to ScoringIDC’s security products and data security taxonomies span the full scope of security
capabilities that might be specified in an RFP. The essence of the scoring methodology
was to compare the RFP specifications against these taxonomies.
A list of security features that are found in public RFPs was determined by document
review. This list was supplemented by additional security features that may be found in
modern PCs and printer devices. IDC’s security products and data security taxonomies
were used to map the security features to a set of eight categories:
• Identity and access management (IAM)
• Endpoint protection (EPP)
• Device security (relating to hardware and firmware)
• Network security
• Web security
• Security and vulnerability management (SVM)
• Data security
• Specialized threat analysis and protection (STAP)
A detailed description of each of these categories is contained in the Appendix.
RFPs were evaluated to determine whether the document contained requirements
falling into one or more of the eight categories. Each RFP was scored based on the
amount of detail provided in each security category, on the following scale:
• None: No security feature relating to the category was found.
• Vague: The security category is mentioned, but no further details are provided.
• Partial: The security category is mentioned, and some specific requirements are
documented but are incomplete or unmeasurable.
• Detailed: The security category is specified to a substantial degree, and
requirements are specific and measurable.
The RFP assessments were conducted in the local language by a number of individual
IDC analysts. Final scores were therefore reviewed to ensure that all RFPs were scored
in the same way, adjusted for differences between countries such as language and
terminology.
COPYRIGHT IDC © 2018 | PAGE 9
Individual RFP assessments in each security category were translated into numerical
scores as follows:
• None — 0
• Vague — 15
• Partial — 70
• Detailed — 100
The numerical scores were chosen to create separation between RFPs of differing
degrees of specification, making it easier to detect patterns and clusters. Other scores
were assessed, and the effect on indices was observed. No significant differences to the
overall positioning of countries, subsectors, device types (PCs or printers), and security
categories were detected. It is arguable that the scoring mechanism penalizes poor
scoring, but it is equally true that it favors RFPs with better security specifications. We
think this is justified given the importance of security to public sector entities.
The numerical scores were then added to create an overall score for each RFP. No
weighting is applied.
The maximum score for any RFP is 100 (scoring 100 in each of the eight security
categories and an average taken).
Individual RFP scores were averaged to create overall indices by country, subsector,
device type (PCs or printers), and security category.
In-Depth AnalysisWeak Consideration Is Given to Security Requirements Within Public Sector Procurement of Both PCs and Printers
Our study examined nine countries globally and found an overall weak level of security
requirements expressed in RFPs relating to the procurement of PCs and printers.
Procurement processes within the public sector do not reflect current, modern security
capabilities, nor do they account for the emerging types of threats that undermine
traditional security approaches (such as malware functioning below the operating
system).
COPYRIGHT IDC © 2018 | PAGE 10
A representative metric is that almost one-third of the examined RFPs have no
consideration of security at all. Of the 130 RFPs examined, 38 instances (29%) scored zero
in our assessment.
Findings by CountryAll Countries Are Poor at Specifying Security Requirements
The country scores show a spread from 7.66 to 37.79, out of a possible 100 (see Figure
1). Though some countries are particularly weak in specifying the security requirements,
it is important to note that no country scores well. The average index is 19.01, and the
median score is 17.25.
The United States, Italy, and Australia score better than average. The United Kingdom,
Spain, France, and Germany score well below the average. Italy had the best scores: This
is chiefly because Italian RFPs consider more security categories than typical. Most RFPs
we analyzed focused on IAM, EPP, and device security; most Italian RFPs also considered
network security, SVM, and data security. Broad security consideration boosts scores. But
again, no country scores highly.
Figure 1. IDC’s Government Procurement Device Security Index, 2018: Country Breakdown
70.00
60.00
50.00
40.00
30.00
20.00
10.00
0
COUNTRY INDEX
Average = 19.01
United States Canada France Germany Estonia Italy United Kingdom SpainAustralia
Source: IDC’s Government Procurement Device Security Study, 2018
COPYRIGHT IDC © 2018 | PAGE 11
To illustrate the overall poor scores, we calculated an optimal benchmark, equivalent
to the average of the highest individual RFP scores in each country. For example, in the
United States, the highest RFP score was 67.50, and in Canada, the highest score was
60.00. The average of the high scores for all countries is 44.69. This optimistic metric is
taken as the benchmark to which countries can reasonably be expected to aspire. No
country scored at or above this benchmark.
Figure 2 shows the spread of scores in each country. In some countries, the highest
scoring RFP is well above the benchmark, but in all cases, the average score (index) is
below the benchmark. In all but one country (Australia), the lowest score for an individual
RFP is zero (no security requirements specified in any security category).
Figure 2. IDC’s Government Procurement Device Security Index, 2018: Country Benchmark
70.00
60.00
50.00
40.00
30.00
20.00
10.00
0
United States Canada France Germany Estonia Italy United Kingdom SpainAustralia
Average = 19.01
Benchmark (Country Basis)
INDEX (AVERAGE SCORE), HIGH SCORE, AND LOW SCORE BY COUNTRY
Note: Figure shows the highest and lowest scores for individual RFPs as well as the average scores. The benchmark is the average of the highest scores across all countries
Source: IDC’s Government Procurement Device Security Study, 2018
COPYRIGHT IDC © 2018 | PAGE 12
Findings by SubsectorNo High-Scoring Subsectors Exist
Intuitively, some subsectors in the public sector domain should score more highly
because they have a greater need for security requirements. Examples of such subsectors
would be defense and justice. However, this hypothesis is challenged by our data: No
subsector scores well. This fact is particularly worrisome given the sensitive nature of data
and operations in key subsectors.
Our RFP selection exercise precluded those procurement exercises that related to
highly sensitive or classified data. Even so, procuring standard equipment into the
administrative departments in defense and justice exposes these subsectors to some of
the most basic cyberthreats. In education and health, where sensitive personal data is
regularly processed, the scores are low enough to be of primary concern (6.77 and 7.31,
respectively) (see Figure 3).
Figure 3. IDC’s Government Procurement Device Security Index, 2018: Subsector Breakdown
70.00
60.00
50.00
40.00
30.00
20.00
10.00
0All
INDEX BY SUBSECTOR FOCUS
Central Defense Education Health Justice Local
Average = 15.94
Source: IDC’s Government Procurement Device Security Study, 2018
COPYRIGHT IDC © 2018 | PAGE 13
Again, we calculated a benchmark, this time based on a subsector basis, to illustrate the
wide range of scores and the overall poor consideration of security. Not surprisingly,
the highest individual RFP scores appear in defense and justice, as well as in local
government. Importantly, though, all subsectors, including defense, revealed RFPs
that scored zero. No subsector index came close to the benchmark. Education is the
worst offender among the subsectors, with 67% of RFPs having no specified security
requirements (see Figure 4).
70.00
60.00
50.00
40.00
30.00
20.00
10.00
0All
INDEX (AVERAGE SCORE), HIGH SCORE, AND LOW SCORE BY SUBSECTOR
Central Defense Education Health Justice Local
Average = 15.94
Benchmark (Subsector Basis)
Note: Figure shows the highest and lowest scores for individual RFPs as well as the average scores. The benchmark is the average of the highest scores across all countries
Source: IDC’s Government Procurement Device Security Study, 2018
Figure 4. IDC’s Government Procurement Device Security Index, 2018: Subsector Breakdown
COPYRIGHT IDC © 2018 | PAGE 14
Findings by Security Category Physical Device Security and IAM Are the Most-Cited Requirements
Across the eight security categories, identity and access management and device
security are the most frequently included requirements (see Figure 5). This makes sense
because these features are typically associated with PCs and printers. However, often the
identity and access management feature specified was “pull print” — the need to input a
pin code or present a physical access card for a print job to begin. This authentication is
indeed security related; IDC believes that the driver, though, is also often related to cost
(the desire to reduce the number of unclaimed and unused print jobs) rather than the
desire to improve security.
Device security, which relates to the physical hardware and firmware shipped from the
factory, is difficult to change once deployed. In the same way, many identity and access
controls are features built into PCs, such as password control and biometrics readers.
Printers tend to offer aftermarket accessories for IAM.
However, endpoint protection scores considerably lower, revealing a procurement
disconnect between hardware purchase and subsequently implemented software-based
endpoint solutions. It’s possible that procurement authorities believe that endpoint
protection for PCs will be installed after delivery. While this may be true, and widely
practiced, very little consideration is given to the system requirements of a PC with
regard to an off-the-shelf endpoint solution. Best practice does specify that the device
needs to be compatible with a particular endpoint solution.
In other categories, data security is worryingly low given the incoming GDPR legislation
in Europe, with its global significance. Procurement approaches seem to be relying on
software-based solutions after device purchase and deployment.
Generally, devices seem to be procured as standalone equipment, even though they are
most likely to be integrated in a networked environment. Little consideration is given to
network security, web security, or integration with security monitoring systems (in the
SVM category). While PCs tend to be integrated into security monitoring systems, it is just
as critical that printers are also integrated to ensure that, if a printer compromise occurs,
security personnel are alerted to the issue.
COPYRIGHT IDC © 2018 | PAGE 15
Web security and analytics capability (STAP) is particularly weak. This shows that RFP
requirements are not considering modern security capabilities or modern threats.
Figure 5. IDC’s Government Procurement Device Security Index, 2018: Security Category Breakdown
35.00
40.00
30.00
25.00
20.00
15.00
10.00
5.00
0
IAM EPP Device security Network security Web security SVM Data security STAP
SECURITY CATEGORY INDEX
Source: IDC’s Government Procurement Device Security Study, 2018
COPYRIGHT IDC © 2018 | PAGE 16
Findings by Device TypeDevice-Based Print Security Features Are Far Less Commonly Specified Than PC Security Features
Device security is the one category in which postdelivery software-based security
solutions cannot be added. As stated previously, this category is one of the two
most cited in our analysis of RFPs. However, it is important to understand whether
procurement authorities genuinely acknowledge the importance of this
particular category given the inability to enhance device security using additional
software solutions.
Printers tend to be often overlooked for security requirements. This is unfortunate
because these devices pose just as much of a risk as PCs. Printers not only are processing
data into physical documents but also are capable of storing documents and can put
sensitive data at risk. In addition, any device not adequately secured, whether a printer or
other IoT device, can put a customer’s entire network infrastructure at risk: Basic security
protections should include secure boot (a hardware root of trust) or whitelisting to
ensure firmware on the device has not been compromised.
A good test is whether printers are required to have more device security than PCs: PCs
are straightforward to upgrade with software-based solutions based on the general-
purpose design and implementation of the open operating system and thus can (at
least theoretically) afford to have less built-in device security. Printers, on the other hand,
are typically not upgraded with the latest firmware because of a lack of understanding
among customers of the risk of these devices. So a reasonable hypothesis is that printers
should have greater device security features specified than PCs.
COPYRIGHT IDC © 2018 | PAGE 17
In fact, our analysis shows the opposite to be true. PC RFPs are 72% more likely to specify
device security requirements than printer RFPs. Device requirements include upgradable
or recoverable BIOS, trusted platform modules, and biometrics or smart card readers
for access control. These features can apply equally to PCs or printers but were rarely
specified in printer RFPs we reviewed.
Printer security has been identified by IDC as a particular blind spot in the consideration
of enterprise security (see Figure 6). Here we have a strong example where this is true. In
the one category where we would expect to see better security requirements for printers
than PCs, procurement authorities failed.
No other security category showed significant differences between PC and printer
requirements.
Figure 6. IDC’s Government Procurement Device Security Index, 2018: Device Security in Printers and PCs
35.00
40.00
45.00
30.00
25.00
20.00
15.00
10.00
5.00
0
Printer devicesecurity
PC devicesecurity
SECURITY CATEGORY INDEX (DEVICE SECURITY ONLY)
Note: Figure shows data for the device security category only; no other security category showed significant differences between PC and printer requirements.
Source: IDC’s Government Procurement Device Security Study, 2018
COPYRIGHT IDC © 2018 | PAGE 18
IMPLICATIONSWhy does security consideration in procurement matter? The lack of security consideration is evidence of a disconnect between the narrative of
Government guidance and the day-to-day operations of procurement. Given the
strength of support for cyberdefense articulated by governments around the world,
registering almost no security mention in requests for proposals of foundational
technologies is surprising. Either the message is not being transmitted downward
to frontline staff or policy and process have not yet been implemented to match the
pro-cybersecurity narrative.
Although the purpose of this study was not to investigate the reasons for a lack of
security consideration in RFPs, we suspect that the answer involves a mix of these
two possible reasons. Public sector organizations, we think, need to do a better job of
communicating security aims and objectives and translating them into procurement
requirements. And the security industry in general needs to work harder to surface the
vulnerabilities that threaten to undermine traditional security practices.
In the (few) best practice cases we found in our analysis, tangible security consideration
was made for both printers and PCs. Such considerations need not be specific functional
requirements of a device but at least an acknowledgement that security is important
and is part of the overall assessment criteria under which RFPs will be evaluated. An
overt statement to the effect that security is important to the buying authority sends an
important signal to device suppliers and manufacturers, encouraging them to explicitly
detail the security features of their devices. It also offers potential for differentiation in a
market known largely as a commodity market.
COPYRIGHT IDC © 2018 | PAGE 19
The second key implication of our research is that security features in modern PCs and
printers are not well known and understood by buying authorities in the public sector.
Again, we think that this is because vulnerabilities are not properly understood, leading
to a lack of concern for security capability. This is particularly an issue with printers,
which continued to be a security blind spot for organizations of all types. Printers are
fully functioning computing devices with network connections, and it is both baffling
and worrisome that they are neglected from a security perspective. A dimension that
was not explored in this research, but is worthy of future investigation, is the potentially
different buying point and decision-maker profile for printers versus PCs. The PC is
traditionally specified by the IT department, which has access to and awareness of
security information, both threats and possible protective measures. We suspect that the
same is not true for printers. They are typically procured through facilities management
functions in organizations and are not subject to security reviews or even to installation
of antimalware products once deployed. The default position seems to be no security
consideration.
That security can be added later may be true. However, there is a lack of evidence of
this thinking: A straightforward antimalware compatibility statement could suffice.
RFPs could state that a feature is not required because it will be added later on. But
such statements are rare indeed (an example is the specification of compatibility with
antimalware software).
And printers are much more difficult to harden after they are shipped. Security solutions
for printer fleets are, for the most part, not available. Even if they were on offer, they
would require additional consideration from asset management systems and from
administrators unfamiliar with printer management and upgrades. Thus the lack of
security consideration in printer procurement is particularly troubling. Even if the more
advanced features are not considered, there is little excuse for not addressing device
and endpoint security or identity management concerns such as passwords and
multifactor authentication.
COPYRIGHT IDC © 2018 | PAGE 20
The purpose of developing a benchmark index is to demonstrate that best — or at
least better — practice does exist and, with a reasonable degree of effort and diligence,
could be achieved by most procurement authorities. That it is not reflects the disconnect
between what government says it does and what is actually specified in procurement
documents. We think this is easy to fix by specifying security features in both PCs
and printers and by raising the overall awareness of security vulnerabilities among all
stakeholders in the public sector.
IDC advises that governments and vendors looking to supply devices such as PCs and
printers work together to improve the cybersecurity measures specified in RFPs and take
care in developing those specifications. Governments should take care to define security
specifications appropriately while maintaining a vendor-agnostic approach. The need of
governments for an open bidding process must be respected.
IDC hopes that by highlighting the inadequate consideration of cybersecurity measures
in hardware device procurement, we can encourage public sector organizations to
improve their overall security maturity and reduce the risk of a damaging security
incident.
COPYRIGHT IDC © 2018 | PAGE 21
APPENDIXTable 1 includes examples of security requirements by security category. These examples
are not meant to represent IDC’s view of what is ideal; rather, they are simply verbatim
textual examples from our sample RFPs. Ideal specifications will vary by use case.
Table 1. Examples of Security Requirements by Security Category
PC requirements
IAM
EPP
The system must include the following hardware-based security devices:
• Integrated embedded Trusted Platform Module (TPM) version 1.2• Biometric (fingerprint) reader• BIOS capability to disable USB boot devices• All systems with NIST SP 800-147–compliant secure BIOS• Kensington security lock cut-out for both system and docking station• Computrace Persistence Module
Value-added security solutions: security: The system manufacturer must provide a single, consolidated, policy-based software tool that controls the system’s entire security portfolio. Specifically, these tools must be branded by the system OEM and must control the following security elements: personal password manager employing a single password vault for single biometric sign-on capability, smart card (if specified) management supporting BIOS-enabled preboot, and smart card authentication or SD card software supporting SD boot authentication or biometric initialization and setup and ongoing preboot authentication. Smart card authentication must support multiple smart cards and both the administration level and the user level. The security management features must be accessible through a single console. This security software must be available on a pressed production CD or preloaded on the default system’s hard drive or available from the default system manufacturer’s website under Windows 7 Professional. Third-party software will not be accepted. The software utility must control the following security attributes: biometric. The manufacturer must offer as an option an end-of-life “shredder” software that conforms to the current U.S. Department of Defense disk-wiping standard. Third-party end-of-life “shredder” software is acceptable by Canada.
• Compatibility with the latest version of Microsoft Windows available• A license for antivirus (Trend Micro) software
COPYRIGHT IDC © 2018 | PAGE 22
Table 1. Examples of Security Requirements by Security Category
Device security
Network security
Web security
• Presence of the security slot for the lock cable • Security password protection for the user and administrator from BIOS • Trusted Platform Module protection — at least version 2.0• All products should be able to be managed by a mobile management system
— in particular, these are the minimum requirements: request passcode, mail account, device query; native separation of personal data from company data; the ability to remotely delete business data including mail, applications, and content without the possibility of recovery (undelete); the ability to remotely delete all device data; and setting VPN accounts
• Setting up WiFi accounts with digital certificate authentication; digital certificate request features from a certification authority; single sign-on functionality; and the ability to remotely install applications silently and without any interaction with the user
• An antivirus service is applied to HTTP and FTP streams from the internet. The table of viruses known is updated as soon as viruses are detected by a specialized laboratory.
• “Incoming” connections are prohibited (only messages from the internet are admitted by the firewall).
• Websites are filtered by blacklist and according to their content.
• Communications switch with improved security through 802.1X hotspot (wireless gateways with WiFi connection and gateway function)
• Built-in high-speed WiFi transmission• That it has several flexible mechanisms for user authentication (such as 802.1X
and UAM) and can place permission depending on the type of user• Management of policies for security• Incorporation of DHCP server, NAT, and other network services, such as guest
mechanism account log-in• Generation of reports• Generation of credits and access fees for visitors, which allows printing through
a ticket printer that can be integrated with the captive portal system
PC requirements
COPYRIGHT IDC © 2018 | PAGE 23
Table 1. Examples of Security Requirements by Security Category
Data security
STAP
• Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and at key internal boundaries of the information systems.
• Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
• Identify, report, and correct information and information system flaws in a timely manner.
• Provide protection from malicious code at appropriate locations within organizational information systems.
• Update malicious code protection mechanisms when new releases are available.• Perform periodic scans of the information system and real-time scans of files
from external sources as files are downloaded, opened, or executed.
• Provide, or provide support for, secure browsing. This could include the necessary encryption for browser access, virtual machine browsing, or virtual browser proxy technology.
SVM The TPM Element Manager enables remote/local configuration and management of Trusted Platform Management modules on computing platforms and allows authorized administrators to take ownership/control of the Trusted Platform Management chip, enabling activation, ownership, and decommissioning of the module as well as archival of recovery keys.
PC requirements
COPYRIGHT IDC © 2018 | PAGE 24
Table 1. Examples of Security Requirements by Security Category
EPP EPP
STAPSTAP
Printers must be compatible with centralized software management software that will allow the creation of uniform security policies and their automatic implementation when connecting devices to the network and the consistent monitoring of compliance with security policies or at the interval specified by the contracting authority, with device security settings (passwords, access certificates, updating, and reporting).
Printers must be compatible with centralized software management software that will allow the creation of uniform security policies and their automatic implementation when connecting devices to the network and the consistent monitoring of compliance with security policies or at the interval specified by the contracting authority, with device security settings (passwords, access certificates, updating, and reporting).
All MFDs and NPs shall have hard drive data encryption or image overwrite after each print, copy, scan, facsimile (fax), and email job. Overwrite shall include, at a minimum, the capability of a hard drive overwrite and overwrite capabilities for flash and any other memory source where data is buffered. The available method shall be described by the contractor for all devices offered under this BPA. MFDs shall provide functional separation, meaning physical and logical separation of fax functions from copy, scan, self-contained document server/repository, and email functions. The contractor shall clearly explain and/or provide documentation that verifies or certifies the separation. All MFDs shall have the ability to password protect fax address books. MFDs and NPs shall offer the ability to encrypt documents being emailed. Encryption must be compliant with FIPS 140-2. MFDs and NPs shall allow access by only approved USB encryption devices and shall be capable of disabling firewire interfaces. MFDs and NPs shall be capable of disabling serial connectors and Bluetooth interfaces.
All MFDs and NPs shall have hard drive data encryption or image overwrite after each print, copy, scan, facsimile (fax), and email job. Overwrite shall include, at a minimum, the capability of a hard drive overwrite and overwrite capabilities for flash and any other memory source where data is buffered. The available method shall be described by the contractor for all devices offered under this BPA. MFDs shall provide functional separation, meaning physical and logical separation of fax functions from copy, scan, self-contained document server/repository, and email functions. The contractor shall clearly explain and/or provide documentation that verifies or certifies the separation. All MFDs shall have the ability to password protect fax address books. MFDs and NPs shall offer the ability to encrypt documents being emailed. Encryption must be compliant with FIPS 140-2. MFDs and NPs shall allow access by only approved USB encryption devices and shall be capable of disabling firewire interfaces. MFDs and NPs shall be capable of disabling serial connectors and Bluetooth interfaces.
IAMIAM The following is a minimum set of features required on each device to support security policy and risk mitigation:
• Allow setting and changing of the authentication information (e.g., passwords and community strings) for all management services.
• Prevent unauthorized physical access to the hard drive using either a locking mechanism or other physical access control measure.
• Implement authenticated access to management controls, allowing access to authorized administrators based on privilege assignments.
Access to the device’s configuration and management functions from the console must be secured against access by nonprivileged or unauthorized individuals. Print, scan, copy, and fax jobs must be secured against unauthorized access and deleted when no longer needed. Securing network printing devices will minimize the loss of confidential data recovered in the event the hard drive is stolen or the printer is otherwise compromised. Wireless direct printing bypasses the print spooler, which prevents authentication of the user and logging of print jobs. Wireless direct printing features must be disabled on MFDs and printers.
The following is a minimum set of features required on each device to support security policy and risk mitigation:
• Allow setting and changing of the authentication information (e.g., passwords and community strings) for all management services.
• Prevent unauthorized physical access to the hard drive using either a locking mechanism or other physical access control measure.
• Implement authenticated access to management controls, allowing access to authorized administrators based on privilege assignments.
Access to the device’s configuration and management functions from the console must be secured against access by nonprivileged or unauthorized individuals. Print, scan, copy, and fax jobs must be secured against unauthorized access and deleted when no longer needed. Securing network printing devices will minimize the loss of confidential data recovered in the event the hard drive is stolen or the printer is otherwise compromised. Wireless direct printing bypasses the print spooler, which prevents authentication of the user and logging of print jobs. Wireless direct printing features must be disabled on MFDs and printers.
Printer requirementsPrinter requirements
COPYRIGHT IDC © 2018 | PAGE 25
Table 1. Examples of Security Requirements by Security Category
Web security
SVM
Network security
The following is a minimum set of features required on each device to support security policy and risk mitigation:• Restrict access to the device based on IP address. It is recommended that all
MFDs and printers be placed on a dedicated network segment or virtual local area network (VLAN) with a discretionary access list to limit access to IPs of the print spoolers and system administrators. With this configuration, users will not be able to directly access the devices but rely on print spoolers and the additional security they provide. Place the device behind a switch, router, or firewall, allowing a discretionary access list to block all traffic to the device except the traffic coming from the print spooler and system administrator IPs.
• With regard to network printing services, the use of TCP/IP is required. MFDs and network printers must be configured using a static IP address. All unnecessary or unauthorized protocols, functions, and services must be disabled to prevent exploitation. Since some vendor firmware upgrades or maintenance actions may reenable these services, it may be necessary to periodically verify these services have remained disabled.
Printer requirements
• Disable unused management interfaces. • Networked printers may support a number of different configuration options
including built-in web servers, file transfer protocol (FTP), telnet, and Simple Network Management Protocol (SNMP). Typically, the built-in web server is used for management. The following options must be disabled and modified as indicated:
Security vulnerability updates (software, solutions, firmware, and associated open source and third-party components):• The MFP or printer and associated software must support vulnerability updates
or patches.• Vulnerability updates or patches must be provided within a reasonable time
frame.• A security vulnerability notification process and repository must be available.
• FTP must be disabled when not in use.• Telnet must be disabled.
SNMP must be disabled when not in use. Note: Whether SNMP is enabled or disabled, both public and private “community strings” must be changed from the vendor default values.
COPYRIGHT IDC © 2018 | PAGE 26
DEFINITIONSDevice SecurityDevice security is the only security category considered that is not part of IDC’s standard
security products taxonomy. It relates to the security features that are built in to the
hardware device itself or to the firmware that is shipped with the device. It can include
chip-level security features as well as built-in authentication support (e.g., a fingerprint
reader), tamper-evident security features, and physical protection support (e.g., a
Kensington lock slot). Secure boot is an increasingly common feature and is important
because such features cannot typically be addressed by bolted-on or third-party
software. Such firmware standards are now available: ISO 19678 is a good example.
Identity and Access ManagementThe IAM market provides a comprehensive set of solutions used to identify users
(employees, customers, contractors, etc.) in an IT environment and control their access
to resources within that environment by associating user rights and restrictions with the
established identity and assigned user accounts.
Table 1. Examples of Security Requirements by Security Category
EPP EPP Behavioral anomaly detection:• The device must evaluate outgoing network connections for anomalous
requests.• The device must stop suspicious requests.• The device must automatically trigger a self-healing reboot.
Data security
The MFP or printer supports AES-256–encrypted print jobs with authenticated job release.
Printer requirements
COPYRIGHT IDC © 2018 | PAGE 27
Network SecurityNetwork security is defined as a combination of software, hardware, and networking
technologies whose predominant function is to protect corporate networks and
network-embedded resources from disruption caused by external threats. IDC has
four submarkets in this category: firewall, unified threat management (UTM), intrusion
detection and prevention, and virtual private network (VPN).
Endpoint ProtectionThe endpoint protection market encompasses products that are designed to protect
endpoints from attack or to protect information residing on endpoints, both physical
and virtual, regardless of OS type — including Windows, Linux, Mac OS, iOS, and Android.
Endpoint protection products provision security using or leveraging an endpoint agent
or client as a core or fundamental component. If a solution does not include a client
or an agent, the solution would be included within another functional market such as
network or core.
Web SecurityWeb security products are deployed on software, appliance, SaaS, and virtual platforms.
The submarkets of web security products include URL filtering, web antimalware, web
application firewall, and web content filtering products. Selected data loss prevention
(DLP) technologies can be included in web security as well. Web security products
protect against both inbound (malware) and outbound (data leakage) threats.
Security and Vulnerability ManagementThe security and vulnerability management market provides a comprehensive set of
solutions that focuses on allowing organizations to determine, interpret, and improve
a company’s risk posture. Software products in this market include those that create,
monitor, and enforce security policy as well as determine the configuration, structure,
and attributes for a given device. Security and vulnerability management products
can also perform assessments and vulnerability scanning, provide vulnerability
remediation and patch management, aggregate and correlate security logs, and provide
management of various security technologies from a single point of control. This
market encompasses two separate yet symbiotic markets: security management and
vulnerability assessment. These two submarkets could stand alone, but they also have
considerable overlap in how they are used by enterprises
COPYRIGHT IDC © 2018 | PAGE 28
Data SecurityCompetitive markets overlap the other logical security products markets. Data
security solutions include encryption, tokenization, data masking, standalone data loss
prevention, collaboration security, information rights management, and file and data
access monitoring and alerting. Products in this competitive market provide messaging
encryption, file folder and full disk encryption, encryption of data in motion, storage
and database encryption, data masking, key management infrastructure, and hardware
security modules. In addition to DLP suites, this market examines the market for data
discovery and classification products, file and data activity monitoring and alerting
solutions, data security products designed for big data environments, secure file sharing
and collaboration tools, and information and digital rights management solutions.
Specialized Threat Analysis and ProtectionThe STAP market overlaps the endpoint, messaging, network, security and vulnerability
management, and web functional markets. The products help protect enterprises from
modern malware and attack techniques that are typically not detected by traditional
signature-based technologies. STAP products use a variety of non-signature-based
protection methods including, but not limited to, sandboxing, behavioral analysis, file
integrity monitoring, telemetric heuristics, containerization, netflow analysis, and threat
intelligence. These solutions are typically tied to on-premise or SaaS-based analytics to
provide alerts and context for incident responders. Some products only detect and
alert, while others have automated remediation components. Although some features
within STAP may appear in other products, this competitive market consists of dedicated
STAP solutions.
COPYRIGHT IDC © 2018 | PAGE 29
About IDCInternational Data Corporation (IDC) is the premier global
provider of market intelligence, advisory services, and
events for the information technology, telecommunications
and consumer technology markets. IDC helps IT
professionals, business executives, and the investment
community make fact-based decisions on technology
purchases and business strategy. More than 1,100 IDC
analysts provide global, regional, and local expertise on
technology and industry opportunities and trends in over
110 countries worldwide. For 50 years, IDC has provided
strategic insights to help our clients achieve their key
business objectives. IDC is a subsidiary of IDG, the world’s
leading technology media, research, and events company.
Global Headquarters5 Speen Street
Framingham, MA 01701
USA
508.872.8200
Twitter: @IDC
idc-community.com
www.idc.com
Copyright NoticeThis IDC research document was published as part of an IDC
continuous intelligence service, providing written research,
analyst interactions, telebriefings, and conferences. Visit
www.idc.com to learn more about IDC subscription and
consulting services. To view a list of IDC offices worldwide,
visit www.idc.com/offices. Please contact the IDC Hotline at
800.343.4952, ext. 7988 (or +1.508.988.7988) or sales@idc.
com for information on applying the price of this document
toward the purchase of an IDC service or for information on
additional copies or web rights.