IDC Government Procurement Device Security Index 2018h20195. · IDC’s Government Procurement Device Security Index, compiled across the nine countries, shows similar patterns of

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


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.


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.


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.


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.


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.


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


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.


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).


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


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



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



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


Figure 4. IDC’s Government Procurement Device Security Index, 2018: Subsector Breakdown


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.


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



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.


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.



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.


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.


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.


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



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



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



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



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.


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.


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


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


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.


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.

Documents

IDC Government Procurement Device Security Index 2018h20195. · IDC’s Government Procurement Device Security Index, compiled across the nine countries, shows similar patterns of