Whitepaper Establishing the Software Engineering Processes

Wi-Fi CERTIFIED™ for WMM™- Support for Multimedia Applicationswith Quality of Service in Wi-Fi® NetworksWi-Fi AllianceSeptember 1, 2004© 2004 Wi-Fi Alliance. All rights reserved. Wi-Fi® is a registered trademark of the Wi-Fi Alliance.Wi-Fi CERTIFIED™, WMM™, WPA™, WPA2™ and Wi-Fi ZONE™ are certification marks of the Wi-Fi Alliance.Executive SummaryMultimedia applications in a Wi-Fi network require Quality of Service (QoS) functionality. QoS enables Wi-Fi access points to prioritize traffic and optimizes the way shared network resources are allocated among different applications. Without QoS, all applications running on different devices have equal opportunity to transmit data frames. That works well for data traffic from applications such as web browsers, file transfers, or email, but it is inadequate for multimedia applications. Voice over Internet Protocol (VoIP), video streaming, and interactive gaming are highly sensitive to latency increases and throughput reductions, and require QoS.To meet this need, the Wi-Fi Alliance started interoperability certification for WMM (Wi-Fi Multimedia) as a profile of the upcoming IEEE 802.11e QoS extensions for 802.11 networks. WMM prioritizes traffic demands from different applications and extends Wi-Fi’s high quality end-user experience from data connectivity to voice, music, and video applications under a wide variety of environment and traffic conditions. WMM defines four access categories (voice, video, best effort, and background) that are used to prioritize traffic so that these applications have access to the necessary network resources. Additionally, WMM-enabled Wi-Fi networks concurrently support legacy devices that lack WMM functionality. The WMM best effort access category and legacy devices transmit with the same priority.The Wi-Fi CERTIFIED for WMM program tests interoperability with WMM and interoperability with existing Wi-Fi devices. The certification program is available to all new Wi-Fi-enabled devices. Existing Wi-Fi devices can receive a software upgrade. Wi-Fi CERTIFIED for WMM is optional, as not all clients need QoS capabilities. The Wi-Fi Alliance has worked closely with the industry and standards bodies to ensure wide adoption of WMM in new CE devices and new multimedia applications.To take advantage of WWM functionality in a Wi-Fi network, three requirements have to be met: (1) the access point is Wi-Fi CERTIFIED for WMM and has WMM enabled; (2) the client (device) that the application is running on must be Wi-Fi CERTIFIED for WMM; and (3) the source application supports WMM.The Wi-Fi Alliance is a nonprofit international trade association that developed the Wi-Fi brand in 1999 to certify interoperability of wireless local area network products based on IEEE 802.11 standards. Wi-Fi Alliance product certification began in March of 2000. The primary mission of the Wi-Fi Alliance is to assure a positive user experience through product interoperability.Table of ContentsEXECUTIVE SUMMARY (I)TABLE OF CONTENTS (II)Introduction (1)The Need for QoS in Wi-Fi Networks (2)Why is QoS Necessary? (3)WMM Offers QoS for Wi-Fi Networks (4)Access Categories (AC) (5)Overview of WMM Operation (7)Scheduled Access (9)The Wi-Fi Alliance Certification Program for WMM (9)Conclusions (10)Additional Resources (11)List of acronyms (11)IntroductionInterest and demand for Wi-Fi multimedia applications and advanced capabilities are growing quickly, spurred by new devices and by the desire of Wi-Fi users to extend the functionality of their networks. In the residential market, Voice over Internet Protocol (VoIP), video streaming, music streaming, and interactive gaming are among the most anticipated applications. In enterprise and public networks, support for VoIP, real time streaming of audio and video content, as well as traffic management, allows network owners to leverage the Wi-Fi infrastructure to offer a richer and more diverse set of services.Quality of Service (QoS) is required to support multimedia applications and advanced traffic management. WMM adds prioritized QoS capabilities to Wi-Fi networks and optimizes their performance when multiple concurring applications, each with different latency and throughput requirements, compete for network resources. By using WMM, end-user satisfaction is maintained in a wider variety of environments and traffic conditions. WMM makes it possible for home network owners and enterprise network managers to decide which data streams are most important and assign them a higher traffic priority.The Wi-Fi Alliance defined WMM as a profile of the upcoming IEEE 802.11e standard and started a program for Wi-Fi CERTIFIED for WMM to satisfy the most urgent needs of the industry for a QoS solution for Wi-Fi networks. An addendum to the IEEE 802.11 standard, 802.11e, is currently being developed and it will include support for QoS in Wi-Fi networks. The 802.11e project began in 1999, and ratification for 802.11e is projected for the end of 2004 or early 2005.The proactive approach taken by the Wi-Fi Alliance with WMM is similar to that followed for WPA™ (Wi-Fi Protected Access™). Wi-Fi CERTIFIED for WPA has allowed manufacturers to offer an interoperable, robust security solution based on 802.11i, a year and a half ahead of the ratification of the standard.Wi-Fi CERTIFIED for WMM is optional for Wi-Fi products since not all applications need QoS, but Wi-Fi CERTIFIED products that do offer QoS are required to be Wi-Fi CERTIFIED for WMM. Wi-Fi CERTIFIED for WMM ensures that products interoperate with each other and are able to coexist with legacy devices that lack WMM functionality.In a Wi-Fi network, WMM functionality requires that both the access point (AP) and the clients running applications that require QoS are Wi-Fi CERTIFIED for WMM and have WMM enabled. At the same time, it is important to realize that WMM-enabled devices can take advantage of their QoS functionality only when using applications that support WMM and can assign the appropriate priority level to the traffic streams they generate.WMM provides prioritized media access and is based on the Enhanced Distributed Channel Access (EDCA) method. It defines four priority classes (voice, video, best effort, and background) to manage traffic from different applications.The rest of the white paper discusses in more detail how Wi-Fi networks benefit from QoS and how WMM will encourage the growth of multimedia applications and advanced network management capabilities, explains how WMM works, and provides additional information about the Wi-Fi Alliance testing program.The Need for QoS in Wi-Fi NetworksQoS functionality in Wi-Fi networks is emerging as a key requirement to support multimedia applications and advanced network traffic management in the residential, enterprise, and public access market segments.Residential market. In the residential market, demand for Wi-Fi multimedia applications is growing rapidly as four key trends emerge:•Wi-Fi home networking is spreading rapidly among broadband households (In a recent report (IDC #31762, August 2004), IDC forecasts that by 2008, 36.7 million US households will have either a data-centric or a media-centric home network), and Wi-Fi has emerged as the clear favorite among wireless technologies for home networks.•Residential broadband penetration has taken off (in Korea, 79% of households have broadband according to PointTopic (World Broadband Statistics Q3 2003, January 2004); the FCC estimates broadband penetration in the US at 26% and growing at an impressive rate of 42% in 2003).•New services, digital content, and new applications (e.g. VoIP, gaming, music streaming) are becoming more widely available, and consumer demand is growing. • A wide range of products addressing digital entertainment connectivity – a substantial market for potential Wi-Fi connectivity – are rapidly entering the market.Annual shipments of such products are expected to grow at a fast pace over the next few years and to reach 120 million units by 2008, according to Parks Associates (Multimedia Networks in the Home - .Analysis and Forecasts, January 2004). Enterprise market. Enterprises urgently need QoS to be able to support wireless VoIP, which can provide significant cost savings and wireless voice connectivity throughout the campus by leveraging the Wi-Fi infrastructure while avoiding the higher costs of cellular voice services. Another application that benefits from WMM is prioritized traffic management, which allows the IT administrator to assign different priority levels to different users. For instance, network administrators may wish to assign a lower priority to visitors sharing the network, or to provide more resources to employees working on critical tasks, or to applications like video streaming or teleconferencing.Public market. Prioritized traffic management is also a key capability for Wi-Fi public access. Use of Wi-Fi ZONEs™ is growing rapidly with the number of active hotspot locations expected to grow to 135,000 by the end of 2006, according to Datamonitor (Public wireless LANs: hotspots - finally heating up - #DMTC0921). Users are increasingly accustomed to VoIP and multimedia applications such as streaming and gaming, and they will expect to be able to use them in Wi-Fi ZONEs as well, putting additional pressure on shared network resources. WMM may be used both to ensure that specific applications (e.g., voice or gaming) have access to the required network resources or that specific users (e.g., those paying higher fees) receive priority access. This will enable service providers to offer premium services and provide support for multimedia applications.Why is QoS Necessary?Traditional Wi-Fi networks give equal access to all connected devices. When traffic demands exceed the available bandwidth, throughput for all data streams is similarly reduced, regardless of the type of data. The impact on user experience, however, is strongly affected by the type of data and by the type of application. A one-second delay in sending a print job from a laptop to a printer is unlikely to be noticed by the user. However, a much smaller increase in latency or a reduction in throughput may disrupt the conversation in a VoIP call, or may result in dropped in frames or a frozen image on the screen in a streamed video application.Non-prioritized, best effort access effectively deals with contention from data applications such as file transfers, email, and Internet and intranet access. Applications such as voice, video and music streaming, and interactive gaming generate data streams that have strict latency and throughput requirements. To ensure a good user experience, traffic from different applications has to be managed and prioritized using QoS.In the residential market, the increasing complexity and functionality of Wi-Fi networks that multimedia applications bring create a more acute need for QoS. CE manufacturers are marketing a wider array of Wi-Fi-enabled devices, such as VoIP phones, TV, VCRs, PVRs, MP3 players, game consoles, and other multimedia players, in addition to Wi-Fi media adapters that enable legacy devices. Network owners are exploring new ways to use their Wi-Fi networks that go beyond connecting a DSL or cable router to one or more laptops or PDAs and possibly a printer (Figure 1). Potential new uses include: •providing wireless voice connectivity within the house through VoIP Wi-Fi phones, either using a VoIP service or through a traditional phone line connectionBroadbandconnectionFigure 1. Wi-Fi multimedia home network•using the Wi-Fi network to distribute content from a media server, PC, or an external broadband connection to any device in the home (TVs, MP3 players, or game consoles)•establishing wireless connectivity between devices in the home (e.g. a DVD player and speakers in different rooms)•supporting peer-to-peer networks for telephony or gaming.Across all the markets, more Wi-Fi-enabled devices in the same network mean more concurrent applications competing with each other, increased traffic demands and, at the same time, higher expectations from users who expect Wi-Fi to match the performance of a wired Ethernet network.WMM Offers QoS for Wi-Fi NetworksThe Wi-Fi Alliance has taken an active approach to promote the development of multimedia and advanced applications by developing the WMM specification and certification program that offers QoS functionality for Wi-Fi networks. Key WMM advantages are:•Interoperability. WMM was developed with a strong commitment to interoperability.It works across device types and manufacturers, and can be implemented by any application that uses Wi-Fi.•Availability. The WMM specification and test plans have been finalized, and Wi-Fi CERTIFIED for WMM is available beginning September 2004. Manufacturers have already started to incorporate support for WMM in new multimedia Wi-Fi devices.Availability of WMM is crucial to support the rapid growth of QoS-based applications because the IEEE draft 802.11e, which will provide QoS support for Wi-Fi networks, has not yet been ratified.•Relationship with IEEE 802.11e. Wi-Fi Alliance members have worked closely with the 802.11e TG to develop QoS for Wi-Fi networks. WMM is a profile of the upcoming IEEE 802.11e QoS extensions for 802.11 networks. The 802.11e draft includes additional capabilities and features that may be included later in the Wi-Fi CERTIFIED for WMM program as optional capabilities. For example, the Wi-Fi Alliance is already developing a test plan for the scheduled access capability. •Wide industry support. As with previous certification efforts, the Wi-Fi Alliance has worked in close collaboration with industry players to facilitate WMM adoption in the market.•Wide appeal. WMM meets the requirement of the residential, SOHO, enterprise, and public access market segments.•User confidence. Through the Wi-Fi Alliance certification program and education efforts, users see the Wi-Fi logo as an assurance of interoperability. Similarly, users will rely on the WMM mark to identify Wi-Fi devices that support QoS and to guide their purchasing decisions.•Global reach. Wi-Fi CERTIFIED for WMM is set to have worldwide recognition, thus making Wi-Fi CERTIFIED for WMM products appealing to customers who need to deploy interoperable solutions across several countries, and capable to meet public agencies and private companies requirements globally.•Coexists with devices that do not support WMM. Most Wi-Fi devices deployed or in the market do not support QoS. This is not likely to change, as many devices and applications do not need QoS capabilities. WMM allows Wi-Fi clients with and without WMM capabilities to coexist in the same network. The APs are, however, required to have WMM functionality to support WMM-enabled clients. The network owner can either buy a Wi-Fi CERTIFIED for WMM AP or apply a Wi-Fi CERTIFIED for WMM software upgrade to deployed APs.•Adapts well to dynamic data rates. This is a key requirement for a technology like Wi-Fi that operates in the license-exempt spectrum and therefore cannot guaranteea constant throughput level.•IETF Differentiated Services (DiffServ). WMM is based on the IETF DiffServ architecture, which is well suited for providing QoS on shared media technologies like Wi-Fi, as it enables effective traffic prioritization without imposing an onerous overhead. Individual data packets are labeled with either IETF DSCP headers or IEEE 802.1d tags.•Compatible with Universal Plug and Play (UPnP) QoS. The common DiffServ foundation enables UPnP QoS to manage WMM, and allows network owners to develop and enforce network-wide policies that apply to the wired and wireless infrastructure.The success of WMM, as well as other Wi-Fi CERTIFIED technologies, depends on manufacturers’ support in new products, which will lead to a constellation of interoperable products that users will be able to combine as desired in their networks.To take advantage of QoS functionality, however, it is equally necessary that multimedia applications support WMM, as they are responsible for assigning the appropriate priority level to data packets. Applications or operating systems that do not support WMM do not have access to the network QoS capabilities. The traffic they generate is treated as best effort, and receives a priority lower than voice and video.Users and CE manufacturers alike will demand WMM functionality in new applications, as this will enable them to work as expected over a Wi-Fi network. Applications developers should add WMM support in new applications that require QoS if they want to reach Wi-Fi users. Resources for application developers are listed in the Appendix.Access Categories (AC)WMM defines four access categories derived from 802.1d, which correspond to priority levels (Table 1). While the four ACs were designed with specific types of traffic (voice, video, best effort, low priority data) and associated priorities in mind, WMM leaves the network owner free to choose the most appropriate network-wide policy and to decide which ACs have priority. For instance, a network owner may prefer to give priority to video streaming over voice. A customized policy for the ACs can be set through aninterface in which default priority levels for ACs can be modified. WMM specifies a protocol used by the AP to communicate the policy to QoS-enabled clients and by the clients to send transmit requests. 802.1d Tags WMM Voice Priority Highest priorityAllows multiple concurrent VoIP calls, with low latency andtoll voice quality7, 6WMM Video Priority Prioritize video traffic above other data trafficOne 802.11g or 802.11a channel can support 3-4 SDTVstreams or 1 HDTV streams 5, 4 WMM Best EffortPriority Traffic from legacy devices, or traffic from applications or devices that lack QoS capabilitiesTraffic less sensitive to latency, but affected by long delays,such as Internet surfing0, 3 WMM BackgroundPriority Low priority traffic (file downloads, print jobs) that does not have strict latency and throughput requirements 2, 1 Table 1. WMM access categories Figure 2 shows an example of how WMM affects throughput for competing data streams. In the top graph, WMM gives a higher priority to the video application than to the other data streams. During the first 10 seconds, both the video and the low priority data stream have sufficient resources. The introduction of a third data stream creates transmission demands that exceed network capacity. WMM gives the video stream a higher priority to ensure that it has sufficient resources. In the bottom graph, WMM is not enabled and, therefore, all traffic streams are given the same access to the wireless medium. In this case, the introduction of the third data stream penalizes all data streams equally.Video priority Background Time (s)T h r o u g h p u t (M b p s )With WMM: video has priority over dataTime (s)T h r o u g h p u t (M b p s )Without WMM: new data stream impacts video(10 Mbps)priority(14 Mbps)Figure 2. Example of effect of WMM on a video streamOverview of WMM OperationWMM is an enhancement to the MAC sublayer to add QoS functionality to Wi-Fi networks. WMM is an extension to the legacy CSMA/CA-based DCF mechanism that gives all devices the same priority and that is based on a best effort, “listen-before-talk” algorithm. Each client waits for a random backoff time, and then it transmits only if no other device is transmitting at that time. This collision avoidance method gives all the devices the opportunity to transmit, but, under high traffic demand conditions, networks get overloaded and performance of all devices is equally affected.WMM introduces traffic prioritization capabilities based on the four ACs listed in Table 1 (the higher the AC, the higher the probability to transmit) that address Distributed Coordination Function’s (DCF) inadequacy to support multimedia applications. The ACs were designed to correspond to 802.1d priorities to facilitate interoperability with QoS policy management mechanisms, such as UPnP. WMM APs coexist with legacy devices (or devices that are not WMM-enabled): packets not assigned to a specific AC are categorized by default as having best effort priority.WMM prioritization works as shown in Figure 3 and Figure 4. Applications assign each data packet to a given AC (Figure 3). Packets are then added to one of four independent transmit queues (one per AC; i.e., voice, video, best effort, or background) in the client. The client has an internal collision resolution mechanism to address collision among different queues, which selects the frames with the highest priority to transmit. The same mechanism deals with external collision, to determine which client should be granted the Opportunity to Transmit (TXOP).Map framesAssignResolve“Air”to ACframesto transmitqueueinternalcollisionFigure 3. Transmit queues within a WMM client The collision resolution algorithm that is responsible for traffic prioritization is probabilistic and depends on two timing parameters that vary for each AC (Figure 4): • the minimum interframe space, or Arbitrary Inter-Frame Space Number (AIFSN) • the Contention Window (CW), sometimes referred to as the Random Backoff Wait. Both values are smaller for high-priority traffic. For each AC, a backoff value is calculated as the sum of the AIFSN and a random value from zero to the CW. The value of the CW varies through time. Initially the CW is set to a value that depends on the AC.After each collision the CW is doubled until a maximum value (also dependent on the AC) is reached. After successful transmission, the CW is reset to its initial, AC dependant value. The AC with the lowest backoff value gets the TXOP. As frames with the highest AC tend to have the lowest backoff values, they are more likely to get a TXOP.Figure 4. WMM AC TimingOnce a client gains a TXOP, it is allowed to transmit for a given time that depends on the AC and the PHY rate. For instance, the TXOP limit ranges from 0.2 ms (background priority) to 3 ms (video priority) in an 802.11a/g network, and from 1.2 ms to 6 ms in an 802.11b network. This bursting capability greatly enhances the efficiency for high data rate traffic, such as AV streaming. In addition, devices operating at higher PHY rates are not penalized when devices that support only lower PHY rates (e.g. because of distance) contend for medium access.WMM has been drafted in coordination with the 802.11e TG, and it is a subset of the QoS capabilities included in the 802.11e draft. WMM is based on the Enhanced Distributed Channel Access (EDCA) as defined by the 802.11e TG. The 802.11e draft includes additional features that may be added to WMM as optional modules, which include Scheduled Access, Direct Link Setup (DLS), Block Acknowledgement, and Power Save. While no timeline has been set yet, the Wi-Fi Alliance expects Scheduled Access to be the first WMM optional capability to be available.Scheduled AccessScheduled access allows applications to reserve network resources based on their traffic characteristics through requests sent by the client to the AP. It supports parameterized, planned access and corresponds to the HCF Controlled Channel Access (HCCA) in 802.11e. Because the impact of backoff delays is lower, scheduled access can reduce on average the network latency by using a centralized scheduling control mechanism. The polling schedule for scheduled access is designed to meet applications’ requirements for throughput and latency by assigning times when applications can transmit. The client sends a reservation request to the AP, which in turn assigns TXOPs to the appropriate traffic streams. The AP assignment depends on several TransmissionVoice Video Best Effort BackgroundSpecification (TSPEC) parameters, such as data rate, PHY rate, packet sizes, service interval, and burst size.Unlike baseline WMM, scheduled access requires that the client knows in advance what resources it needs and that the AP makes assumptions (e.g. minimum vs. maximum packet size, minimum vs. maximum PHY rate, service start time, surplus bandwidth reserved for re-tries) to schedule concurrent traffic effectively.The Wi-Fi Alliance Certification Program for WMMThe Wi-Fi Alliance is committed to promoting strong interoperability among Wi-Fi devices through product certification. To ensure interoperability among QoS-enabled devices, the Wi-Fi Alliance operates the Wi-Fi CERTIFIED for WMM program that started in September 2004.As with other certification programs offered by the Wi-Fi Alliance (802.11a/b/g and WPA), certification tests are conducted in independent labs accredited by the Wi-Fi Alliance. Certification ensures that the product is interoperable with other Wi-Fi CERTIFIED for WMM products. Manufacturers receive a Wi-Fi Interoperability Certificate (Figure 5) that indicates WMM under the new Multimedia category.Figure 5. The Wi-Fi Interoperability CertificateWMM is an optional component of the Wi-Fi CERTIFIED process. This is because not all Wi-Fi products require QoS functionality, and all Wi-Fi CERTIFIED products, whether or not WMM-enabled, can operate in a Wi-Fi network with WMM. New and existing Wi-FiCERTIFIED products can be submitted for Wi-Fi CERTIFIED for WMM. It is anticipated that many existing Wi-Fi CERTIFIED products will be able to support WMM through a simple software upgrade. For new products, Wi-Fi CERTIFIED for WMM is part of the regular Wi-Fi CERTIFIED process, which includes a PHY option (802.11a/b/g) and WPA. Wi-Fi CERTIFIED for WMM is not granted to products that are not Wi-Fi CERTIFIED. Conversely, all new products that offer QoS capabilities are required to pass WMM tests to become Wi-Fi CERTIFIED.Certification is currently limited to the WMM baseline capability. Additional capabilities may be added in the future as optional items. Only products that have passed WMM tests are eligible for certification for additional capabilities. The Wi-Fi Alliance is already developing a test plan for the scheduled access capability. The timeline and choice of additional capabilities will be driven by market demand.Additional information about the Wi-Fi Alliance certification program and a database ofWi-Fi CERTIFIED products can be accessed at .ConclusionsWMM extends Wi-Fi networks’ functionality to include QoS, and to support a wide range of multimedia application and advanced capabilities, which include:• VoIP•Video and music streaming•Interactive gaming•Prioritized traffic management.WMM is a QoS solution with industry-wide support that offers strong interoperability, meets the requirements of all market segments, and has global reach. It is available now and will be interoperable with 802.11e. The Wi-Fi Alliance has launched a WMM certification program that establishes a solid foundation for the growth of the Wi-Fi multimedia market, and that facilitates the development of interoperable devices and applications with QoS capabilities. At the same time, WMM greatly improves the end-user experience and enables a wider, more efficient use of Wi-Fi networks everywhere. Additional ResourcesDifferentiated Services:/html.charters/diffserv-charter.htmlMicrosoft Windows Application-Driven QoS - Traffic Control API (TC API):/library/en-us/qos/qos/traffic_control_api.aspMicrosoft Windows GQoS interface for Winsock 2 (through Windows XP):/msdnmag/issues/01/04/QOS/。

White Paper:Linking Images With ApplicationsThe TWAIN Working GroupMay, 2011IntroductionThe TWAIN initiative was originally launched in 1992 by leading industry vendors who recognized a need for a standard software protocol and applications programming interface (API) that regulates communication between software applications and imaging devices (the source of the data). TWAIN defines that standard and is maintained by the TWAIN Working Group.The three key elements are the application software, the Source Manager software and the Data Source software. The application uses the TWAIN toolkit which is shipped for free.The word TWAIN is not a n official acronym, however, it is widely known as “T echnologyW ithout A n I nteresting N ame.”For more information on the history of TWAIN, see our White Paper, The Origin of TWAIN. VisionThe TWAIN Working Group is a not-for-profit organization which represents the imaging industry. TWAIN’s purpose is to provide and foster a universal public standard which links applications and image acquisition devices. The ongoing mission of the organization is to continue to enhance the standard to accommodate future technologies.Goals of the TWAIN StandardTWAIN was designed to provide a consistent, easy integration of image data between sophisticated input devices and software applications. The following remain the Working Group’s goals for the standard:∙Ensure image-handling software and hardware compatibility∙Keep the specification current with state of practice software and hardware∙Maintain backward compatibility∙Multiple platform support∙Maintain and distribute a no-charge developer’s toolkit∙Ensure ease of implementation∙Promote the adoption of the standard∙Define TWAIN test guidelinesMilestonesSince the initial 1.0 release, TWAIN has been dramatically enhanced to meet the ongoing needs of the imaging industry. Significant milestones for TWAIN include:∙Version 2.1 – Supported on Windows 7 (32 and 64 bit), and support for automatic color detection∙Version 2.0 – Unix/Linux support, check scanning support, open source; and 64-bit ∙Version 1.9 – ICC Color profiles and Mac support for Cocoa∙Version 1.8 – Further enhanced production scanning support∙Version 1.7 – Production scanning feature set∙Version 1.6 - Page length detection and buffer transfer∙Version 1.5 – Performance enhancementsAttributes of the Standard∙Royalty free – TWAIN is free to be used by any hardware manufacturer or software application provider.∙Multiple platform support – TWAIN provides cross platform support for Windows, Unix/Linux and Macintosh. The standard offers native support for 32-bit and 64-bitsystems. It also works on virtual machines such as WOW64 on Window 64-bit systems.∙Wide range of capture devices – suitable for a wide range of devices including digital cameras and all segments of scanners from personal to high-end production.∙Speed –TWAIN is capable of handling scanners’ rated speed from the smallest and slowest models to the largest and fastest production models.∙Self-Certification – Complimenting the standard are free testing tools that enable manufacturers to certify their TWAIN data sources and drivers against the latest version of the TWAIN specification. This provides assurance to application developers that the drivers maintain a high standard of compliance and robustness. A list of self-certifieddrivers is available from the TWAIN web site at .∙Feature rich – The standard provides a rich set of capabilities and operations ensuring its suitability for a wide variety of image capture devices.∙Customizable – TWAIN permits developers to enhance their data sources with their own custom features and support this seamlessly with the standard feature set.∙Active standard – The TWAIN specification undergoes continuous active development.TWAIN provides a forum to solicit feedback and suggestions from the TWAINcommunity. Community feedback is reviewed weekly by the technical subcommittee.The technical committee makes enhancement recommendations to the TWAIN’s board of directors at their quarterly meetings.∙Open source Data Source Manager (DSM) – The TWAIN 2.x DSM is open source under the LGPL license. This improves logging to help developers diagnose problems, allows the community to examine the source code and encourages the developer community to make recommendations for enhancing the standard.∙Open source Sample Application and Data Source code – Aids developers working on applications and data sources.∙Backward and forward compatibility since 1992 –Applications and data sources are able to communicate and perform their functions regardless of the version of the TWAIN protocol they support or the data source manager operating between them.∙Easy implementation - The interface, its documentation and sample code are well structured, well written, and intuitively designed for developers to learn and write the code for it.∙Production capable – TWAIN describes interfaces for high-end production scanning solutions that aid in indexing and batch management. Capabilities include duplexscanning, printing and endorsing, barcode and patch code detection.∙Multi-data capacity – The TWAIN data interchange mechanism enables data transmission in most existing file formats and will accommodate future formats as they become available.∙Profile management – The TWAIN standard describes a method for an application to manage snapshots of data source settings allowing complete control of a Data Source’s full feature set with minimal programming.∙Asynchronous notification – TWAIN provides ways for applications to be immediately notified of important events such as paper jams and device disconnects.∙Multiple images of single document –TWAIN allows applications to capture multiple images of the same document, for instance, one suitable for archival purposes and one for optical character recognition (OCR).∙Longevity – The on-going goal of the standard is to provide a single solution for the industry that will last for many years and will accommodate all future technologies.∙Broad adoption – The well-defined interface has enabled the majority of leading hardware and software developers to provide drivers for their devices or include support through their applications.∙Market visibility – TWAIN provides visibility for its supporters including hardware, manufacturers, application providers, developers and providers of testing services and tools via the resource section of the TWAIN website.Future DirectionThe TWAIN Working Group is responsive to the needs of the industry. Careful analysis of the community’s feedback has helped the working group to target four key initiatives to keep TWAIN as the continued image acquisition standard of choice for developers worldwide.∙Enhanced Communication – TWAIN will offer a new API specification for applications, allowing access to any TWAIN data source (32-bit or 64-bit), while also maintaining the legacy TWAIN API.∙Driverless Support – The new TWAIN API will be suitable for direct communication with a device, obviating the need for an installed driver from the vendor.∙Remote Access – Scanners and applications will be able to run on separate systems, enabling various kinds of cloud solutions.∙Out of Process – Legacy data sources will run in a backend process under the new TWAIN API, freeing resources for the application, making better use of multi-processor systems and improving robustness.We believe these initiatives provide a viable technological strategy that result in the following significant enhancements:∙ A suitable TWAIN interface for any mobile or desktop device∙Simplified API for application developers∙The same level of standard and custom control of the scanner provided today∙Ease of use with any programming language∙Improved problem diagnosis and debugging capabilities∙Greater reliability∙Complete platform independence∙Improved localization support using UTF-8The TWAIN deliverables will remain:∙ A Data Source Manager,∙The specification, and∙Appropriate Sample CodeThe TWAIN Working Group remains committed to backward compatibility as it has through every phase of the TWAIN Specification’s evolution.MembersThe TWAIN standard is backed and supported by leading hardware and software manufacturers who are committed to the broad interest of the industry. TWAIN members lay aside their own company interest in order to represent a wide spectrum of application developers and hardware manufacturers.Current Board Members include:∙Adobe Systems Incorporated∙AnyDoc Software Inc.∙Atalasoft∙Avision∙Fujitsu Computer Products of America∙J.F.L. Peripheral Solutions Inc.∙Eastman Kodak CompanyCurrent Associate Members include:∙Epson∙Dynamsoft∙Hewlett-PackardMembershipMaintaining the TWAIN standard requires extensive research and development. The TWAIN Working Group is always looking for new members who:∙Embrace the technology∙Are committed to furthering the standard∙Will make a significant contribution with technical and marketing expertiseFor information on Associate or Board membership and to review our bylaws, please email admin@.。

SECURITY AND PRIVACY WHITE PAPERPoly PanoPart 3725-85466-001Version 05October 2023IntroductionThis white paper addresses security and privacy related information for Poly Pano and describes the security features and access controls in the processing of personally identifiable information (PII) or personal data and customer data in conjunction with Pano. HP | Poly uses such data in a manner consistent with the HP Privacy Statement and this white paper (as may be updated from time to time). This white paper is supplemental to the HP Privacy Statement. The most current version of this white paper will be available on HP | Poly’s website.Pano is designed for sharing and interacting with content using mobile devices, computer systems, and the Pano App. Pano is an on-premises device that can further integrate with the HP | Poly Cloud Service.Security at HP | PolySecurity is always a critical consideration for all products and services. HP | Poly’s Information Security Management System (ISMS) has achieved ISO 27001:2013 certification. ISO/IEC 27001 is the most widely accepted international standard for information security best practices.Product security at HP | Poly is managed through the HP | Poly Security Office (PSO), which oversees secure software development standards and guidelines. The HP | Poly Product Security Standards align with NIST Special Publication 800-53, ISO/IEC 27001:2013, and OWASP for application security. Guidelines, standards, and policies are implemented to provide our developers industry approved methods for adhering to the HP | Poly Product Security Standards.Secure Software Development Life CycleHP | Poly follows a secure software development life cycle (S-SDLC) with an emphasis on security throughout the product development processes. Every phase of development process ensures security by establishing security requirements alongside functional requirements as part of initial design. Architecture reviews, code reviews, internal penetration testing, and attack surface analysis are performed to verify the implementation.The S-SDLC implemented by HP | Poly also includes a significant emphasis on risk analysis and vulnerability management. To increase the security posture of HP | Poly products, a defense-in-depth model is systematically incorporated through layered defenses. The principle of least privilege is always followed. Access is disabled or restricted to system services nonessential to standard operation.Standards-based Static Application Security Testing (SAST) and patch management is a cornerstone of our S-SDLC.Privacy by DesignHP | Poly implements internal policies and measures based on perceived risks which meet the principles of data protection by design and data protection by default. Such measures consist of minimizing the processing of personal data, anonymizing personal data as soon as possible, transparently documenting the functions and processing of personal data, and providing features which enable the data subject to exercise any rights they may have.When developing, designing, selecting, and using applications, services and products that are based on the processing of personal data or process personal data to fulfill their task, HP | Poly considers the right to data protection with due regard.Security by DesignHP | Poly follows Security by Design principles throughout our product creation and delivery lifecycle which includes considerations for confidentiality, integrity (data and systems), and availability. These extend to all systems that HP | Poly uses – both on-premises and in the cloud as well as to the development, delivery, and support of HP | Poly products, cloud services, and managed services.The foundational principles which serve as the basis of HP | Poly’s security practices include:1. Security is required, not optional2. Secure by default, Secure by design3. Defense-in-depth4. Understand and assess vulnerabilities and threats5. Security testing and validation6. Manage, monitor, and maintain security posture7. End-to-end security: full lifecycle protectionSecurity TestingBoth static and dynamic vulnerability scanning as well as penetration testing are regularly performed for production releases and against our internal corporate network by both internal and external test teams.Patches are evaluated and applied in a timely fashion based on perceived risk as indicated by CVSSv3 scores.Change ManagementA formal change management process is followed by all teams at HP | Poly to minimize any impact on the services provided to the customers. All changes implemented to Poly Pano and related HP | Poly cloud services go through vigorous quality assurance testing where all functional and security requirements are verified. Once Quality Assurance approves the changes, the changes are pushed to a staging environment for UAT (User Acceptance Testing). Only after final approval from stakeholders, changes are implemented in production. While emergency changes are processed on a much faster timeline, risk is evaluated, and approvals are obtained from stakeholders prior to applying any changes in production.Data ProcessingPoly Pano collects and processes data related to sharing and annotating content:•Content shared to the device•Annotations made to the content•Device and room names•Device IP, MAC addresses, and serial numbers •Pairing configuration with Poly RealPresence Group Series (when configured) including IPaddress, administrator name, and password ofpaired devices Pano App, when used, collects, and processes the following additional data related to sharing and annotating content, and to serve connectivity and troubleshooting:•Shared document filenames and types •Content shared to the device•Annotations made to the content•User actions including login type, pairing details and duration, PIN usage, and exceptionmessages•Platform details including OS and version, system language, hardware specifics such asCPU, GPU, memory size, manufacturer, andmodelAdditionally, with HP | Poly Cloud Service integrated:•Pano device information including device and room names, IP, MAC addresses, and serialnumbers•Microsoft tenant information including tenant domain, name, GUID, and e-mail (global ITadmin)•Authentication provider (if enabled) including name, client ID, client secret, tenant, and tenantIDPurpose of ProcessingPoly Pano processes information for the following purposes:Access ManagementConfiguration of device administration, content sharing rules, and integration with HP | Poly Cloud Service can be performed via an administrative web interface.Share and Annotate ContentPano primarily serves to allow users to collaboratively share data and annotate the shared content with a feature to save the shared and annotated content.Personal data is processed, only as it is relevant to the configuration of Pano and sharing of content and annotations.How Customer Data is Stored and ProtectedThe HP | Poly Cloud Service is hosted in the Microsoft Azure Cloud, in a data center located in the United States region of the Americas geography. Access to servers is limited to only authorized staff members. The servers are not directly accessible from outside the data center. They are accessed only via a secure ‘bastion’ server, with access limited to a small cohort of authorized HP | Poly Cloud Service personnel.HP | Poly may change the location of the HP | Poly Cloud Service in the future. Details of any such change shall be set forth in the latest copy of this white paper available on the HP | Poly website.For transferring personal data of E.U. customers to the U.S., HP | Poly uses an Intragroup Data Transfer Agreement incorporating the E.U. Standard Contractual Clauses as the transfer mechanism. Each HP | Poly Cloud Service customer’s data resides in the data center in a multi-tenant system and is compartmentalized using access controls to provide data isolation between HP | Poly customers. All customer data is encrypted both at rest and in transit using strong cryptography.All customer data is backed up daily. Normal access controls of authorized users and data security policies are followed for all backup data. No physical transport of backup media occurs. The backup data during rest and while in transit is encrypted using AES-256.Data PortabilityPoly Pano administrators can download the following customer data from the Pano:•System logs (as generated)Pano users connected with Pano App can download the following customer data, during an active session, with content saving enabled:•Saved content and annotations•Pano App logs (as generated)Data Deletion and RetentionFor customers who integrate with the HP | Poly Cloud Service, HP | Poly may retain customer data for as long as needed to provide the customer with any HP | Poly cloud services for which they have subscribed and for product improvement purposes. When a customer makes a request for deletion to ******************, HP | Poly will delete the requested data within 30 days, unless the data is required to provide the service to customer.HP | Poly may “anonymize” personal data in lieu of deletion. The anonymization process is irreversible and includes but is not limited to searching and sanitizing all customer-specific data (e.g., name, site information and IP address) with randomly generated alphanumeric characters.Secure DeploymentDeployment of Poly Pano is designed to support a variety of scenarios and work environments. Please consult the Pano Administrator Guide and Pano Deployment Guide for further details regarding deployment configurations and options.Cryptographic SecurityPoly Pano uses secure communication channels for all connections with content sharing devices, over data networks, and with integration to cloud services.Modules and TLS cipher suites implemented in the Pano and HP | Poly Cloud Service are open (i.e., publicly disclosed) and have been peer reviewed. Cryptographic libraries are regularly updated.Pano App implements OpenSSL cryptographic libraries on the system where the application is installed. Pano App will encrypt the HTTPS data stream to Pano over port 443, using TLS 1.2 and symmetric encryption algorithms. Secure communication channels also underpin the optional integration of Pano and Pano App to the HP | Poly Cloud Service.HTTPS (443) using TLS 1.2:•Compression: disabled•RFC 5746 renegotiationo Client-initiated: disabled•Ciphers:o AES 128/256o Key Exchange: ECDHE 256o SHA, SHA256, and SHA384 hashingCustomer access to HP | Poly Cloud Service administration, through the tenant web portal, will support HTTPS over port 443 using either TLS 1.1 or TLS 1.2. Otherwise, as noted above, with the following ciphers:•AES 128/256 (CBC, GCM)•Key Exchange: DHE 2048, ECDHE 256 •SHA, SHA256, and SHA384 hashingHP | Poly Cloud Service Integration (Optional) Poly Pano can be integrated with the HP | Poly Cloud Service. The service is hosted in a datacenter in the United States within the Microsoft Azure cloud to leverage the scalability, availability, and geographic redundancy offered with such an environment.Each HP | Poly Cloud Service customer is provided at least one tenant account that is created when the customer activates their HP | Poly Cloud Service. These accounts use an email address as the user ID. The email address is verified via an email that contains an activation link, allowing the user to configure a password for the account. Once signed in, users can then manage their passwords as needed, with the ability to reset their password if it is forgotten or change it at their discretion. All local passwords are stored in 1-way encrypted format using SHA-256 hashing.AuthenticationIt is also possible to federate the HP | Poly Cloud Service to the customer’s enterprise authentication service. The HP | Poly Cloud Service supports federation via OAuth 2.0 to both Microsoft Office365/Azure AD and to Microsoft Active Directory (via Active Directory Federation Services 3.0). This allows users to sign in with their enterprise user account credentials to the HP | Poly Cloud Service by entering them into the federated authentication provider’s own sign-in page and thus enjoy whatever level of Single Sign On (SSO) integration has been configured within their organization.The HP | Poly Cloud Service uses access tokens from the authentication provider that grant it limited and controlled access to resources owned by a user.•Access tokens are not stored by the cloud service. They are discarded after being used toobtain basic user profile information (user emailaddress, user display name).•Access tokens have limited lifetimes controlled by the authentication provider.Disaster Recovery and Business ContinuityPoly Pano is deployed on customer premises. Primary responsibility for Disaster Recovery and Business Continuity resides with the customer.Additionally, the Poly Trio conferencing system is architected to provide high reliability, resiliency and security.HP | Poly has a Business Continuity and Disaster Recovery Plan reviewed and approved by management to ensure that we are appropriately prepared to respond to an unexpected disaster event. HP | Poly tests disaster recovery processes and procedures on an annual basis. We use the results of this testing process to evaluate our preparedness for disasters and to validate the completeness and accuracy of our policies and procedures.Security Incident ResponseThe HP | Poly Security Office (PSO) promptly investigates reported anomalies and suspected security breaches on an enterprise-wide level. You may contact the PSO directly at**************************The PSO team works proactively with customers, independent security researchers, consultants, industry organizations, and other suppliers to identify possible security issues with HP | Poly products and networks. HP | Poly security advisories and bulletins can be found on the HP Customer Support website.SubprocessorsHP | Poly uses certain subprocessors to assist in providing our products and services. A subprocessor is a third-party data processor who, on behalf of HP | Poly, processes customer data. Prior to engaging a subprocessor, HP | Poly executes an agreement with the subprocessor that is in accordance with applicable data protection laws.The subprocessor list here identifies HP | Poly’s authorized subprocessors and includes their name, purpose, location, and website. For questions, please contact ******************.Prior to engagement, suppliers that may process data on behalf of HP | Poly must undergo a privacy and security assessment. The assessment process is designed to identify deficiencies in privacy practices or security gaps and make recommendations for reduction of risk. Suppliers that cannot meet the security requirements are disqualified.Additional ResourcesTo learn more about Poly Pano, visit our website.DisclaimerThis white paper is provided for informational purposes only and does not convey any legal rights to any intellectual property in any HP | Poly product. You may copy and use this paper for your internal reference purposes only. HP | POLY MAKES NO WARRANTIES, EXPRESS OR IMPLIED OR STATUTORY AS TO THE INFORMATION IN THIS WHITE PAPER. THIS WHITE PAPER IS PROVIDED “AS IS” AND MAY BE UPDATED BY HP | POLY FROM TIME TO TIME. To review the most current version of this white paper, please visit our website.© 2023 HP, Inc. All rights reserved. Poly and the propeller design are trademarks of HP, Inc. The Bluetooth trademark is owned by Bluetooth SIG, Inc., and any use of the mark by HP, Inc. is under license. All other trademarks are the property。

MTR-06W0000035MITRE TECHNICAL REPORTGraph-based Worm DetectionOn Operational Enterprise NetworksApril 2006Daniel R. EllisJohn G. AikenAdam M. McLeodDavid R. KepplerPaul G. Amman, George Mason UniversitySponsor: MITRE Corporation Contract No.:Dept. No.: G024 Project No.:05MSR109 Derived By: Downgrade To:Declassify On:The views, opinions and/or findings contained in this report are those ofThe MITRE Corporation and should not be construed as an officialGovernment position, policy, or decision, unless designated by otherdocumentation.2006 The MITRE Corporation. All Rights Reserved.Corporate HeadquartersMcLean, VirginiaMITRE Department Approval: ______________________________Ph.D.Johnson,DaleHeadDepartmentDepartmentG024Project Leader Approval: ______________________________EllisR.DanielInvestigatorPrincipal&ResponseDetectionWormAutomatedProject MITRE-SponsoredResearchAbstractThe most significant open challenge to the worm defense community is to develop a sensitive detection method that can detect new worms in real time with a tolerable false alarm rate. This paper presents a graph-based detection system and validates it on operational enterprise network data. We argue that the result is significantly closer to solving this challenge than other published works.We show that a graph-based approach to worm detection in an enterprise network can detect a broad range of active worms with a false alarm rate of less than twice per day. The supporting analysis comes from running the detection algorithm on a real enterprise network. The sensitivity results are significantly better than what is reported in the literature. We can detect all active, fast-spreading unimodal worms, including hit-list, topological, subnet-scanning, and meta-server worms.1IntroductionWorm attacks have been a fact of life for many years,and there is little reason to expect them to disappear.Although no one has yet released a worm with the saturation level and spreading speed that the academic community has shown to be within reach[10],modern worms have still managed to infect large portions of the Internet in minutes.For example,the Slammer worm[5]infected over95%of all vulnerable hosts across the Internet in less than10minutes.Such exceptional speed was possible even when it used an ineffective targeting method(randomly selecting32-bit IP addresses)and affected a small population(approx.75,000 hosts).A targeted attack against these hosts could have infected them all in less than a second[10].Naturally,the time fromfirst infection in an enterprise network to saturation of that network is even less than the time required for saturation of the Internet.Further,worms may be launched without warning,and without fore-knowledge of the exploits used.At these speeds it is impossible for humans to be an integral part of the detection and response process,thus we require automatic detection and response.Possible automated responses span a spectrum of impact to the enterprise network and includefiltering traffic or quarantining of hosts identi-fied as infected.All responses require a detection component to trigger and inform the response.The accuracy,sensitivity,and performance of the response system depends on the detection system.To complicate the problem space,any response carries a considerable cost in terms of lost productivity,not to mention sheer annoyance on the part of network users,as responses must disrupt some network traffic–ideally,as little non-worm traffic as possible.In many cases,a worm-response system which routinely dis-ables significant parts of an enterprise’s network based on false alarms may be more damaging than simply enduring periodic worm damage.Thus worm-detection sys-tems require very low false alarm rates(FAR),not only in terms of internal“alarm counts”within the detection system,but also in terms of the user-visible network impact the associated responses would have.We developed a worm-detection system,based on detecting causal trees in graphs of communication behavior,and validated this system using a year-long trace of a major enterprise network.We believe that our results are significantly closer to solving some of the major problems in worm detection,as it is both sen-sitive(able to detect many classes of worms),accurate(a FAR which averages<2 events/day),and efficient(able to run at super-real-time when processing traces).Our worm-detection algorithm works by constructing a graph of network com-munication,and looking for specific behavioral signatures[1]which are indicative of a propagating worm.We then tune our algorithm’s parameters to minimize the FAR,and use the resulting settings.1We validated our algorithm using several techniques.We evaluated both perfor-mance and accuracy by,first,tuning and then applying this algorithm to a separate nine months’worth of traces from a significant portion of a target network’s op-erationally critical enterprise network.We collected complete header traces from several adjacent class-C networks,including a significant amount of intra-switch traffic.Over the course of a year’s worth of data,our algorithm produces an average FAR of slightly more than3.1per day,despite our test network’s somewhat un-structured nature.We determined that there were three Domain Controllers(DCs) which were not on the monitored networks,but who’s communication created a worm-like signature on port137.We also detected a corporate network scanner sweeping the internal network for vulnerabilities.White-listing the DCs and scan-ner reduced the FAR to an average of1.6/day.(Un)Fortunately for(us)the target network,there were no worms observed in the data.Our prototype is also fast,able to process these traces at over10x real time,de-spite an inefficient Java implementation.Additionally,since our algorithm is based on communication patterns,we do not need to perform deep packet inspection, reassembly,or other complex network transformations.For sensitivity,we manually constructed graphs which represent typical in-fection scenarios for worm outbreaks,including hit-list worms using pessimistic assumptions.We show that these graphs are distinct from normal traffic that our algorithm can detect them quickly.In the case of a worm with the spreading prop-erties of Zotob,we show that it is feasible to detect the presence of the worm on the target enterprise network when only one of the600vulnerable hosts on the network has been infected by the one originally infected host.Paper Outline The paper is outlined as follows.Section2describes the require-ments for a real-time worm detection system.Section3compares our approach with the literature and articulates our contributions.Section4provides the detec-tion model.Section5describes the system deployed and its environment.It also contains a description of how the system was tuned and how one would expect to apply this system in another environment.Sections6and7provide an analy-sis of the sensitivity and accuracy of the approach,respectively,for a given set of thresholds.Section8summarizes our conclusions and presents future work.2Real-Time Worm Detection RequirementsWeaver et al.[14]articulated three key metrics for evaluating a worm detection system:accuracy,performance,and sensitivity.We demonstrate that our approach is more sensitive than what is described in the literature,with acceptable accuracy.2We also provide evidence that it can be stood up in real-time.2.1AccuracyWe use two metrics for accuracy.The most familiar is the FAR.Since multiple alerts related to the same activity may sound in quick succession,the FAR alone does not relate well to the operational experience of a typical intrusion detection analyst(IDA).If a series of alerts related to the same alarm are generated in quick succession,the IDA will normally only count them as one“alarm.”This gives rise to the notion of an alarm deadband.Each alarm corresponds to a temporal cluster of one or more alerts related to the same event.The resulting deadbanded FAR is normally lower than the undeadbanded FAR and reflects an IDA’s operational concept of a FAR.The FAR of1.6per day we claim for our system on the target network and use throughout the paper is the deadbanded FAR.Deadbanding alarms has not yet been applied in intrusion-detection-related work,although its conceptual cousin–correlation–has been an area of active re-search.This is because the signal being deadbanded(alerts)are of such different types and relates to different events.However,in our system they are all of the same type and it is often the case that one alert(indicating a single host to be in-fected)will be quickly followed with others.Measuring a detection system this way more closely approximates impact on the IDA’s experience.They are going to care more about how often the automated worm detection system needs looking at than the number of diagnosed infections associated with an alarm.In essence,the alarms raised by our system are inherently correlated.Some may see deadbanding as a trick to lower one’s FAR.To counter-balance that concern,we complement the FAR using the typical signal processing technique of marking the duration of the deadband(the time window for which we keep state)as being in an alarm state for its entire duration.We count not only the number of false alarms but the amount of time that the“alarm light”is on,which leads to our next accuracy metric.The annoyance percentile(AP)reflects the amount of time the alarm“light”is on1.Our approach achieves an AP of less than2%.This implies that the alarm light is on less that30minutes per ing both metrics to measure the accuracy of an automated worm detection system accounts for the impact of the false alarm rate on the operational IDA in a a novel and more meaningful way than simply using the FAR.The approach described in this paper has been validated on roughly a year’s worth of operational,internal enterprise network traffic.The target enterprise has1Just because the detection system’s light is on does not mean the corresponding response system is active.These accuracy metrics approximate the negative impact of FAR rate on the operational IDA,not on the end-user.3an academic culture:there are few constraints on the choices in applications and approaches employees use to achieve results.With such an unconstrained envi-ronment we expected to see lots of unexpected behavior,some of it worm-like in its manifestation.While unexpected traffic patterns were observed,only a small percentage was worm-like.There are network applications that create topologies that have worm-like features and they are discussed at the end of the following subsection.We do not claim to detect worm that target P2P applications.2.2SensitivitySensitivity measures how many true alarms are actually detected.It is impossible to measure sensitivity perfectly without either a general model for all worms of interest,including their effect on the normal network traffic,or an emulation of all worms of interest.Since we have neither of these,we are limited to analytical scenarios.The data collected so far is ideally suited to accuracy analysis,but not to sensitivity analysis.We are working on a software tool that will safely generate configurable,emulated worm traffic across operational network environments.An approach to the worm detection problem can be evaluated by the subspace of worms which can be detected.Most published detection approaches to date are able to detect subclasses of worms based on the spreading strategy and polymor-phic attributes.In addition to the qualitative subspace evaluation,we can evaluate worm detection systems’sensitivity using historical or well-defined hypothetical worms.We propose two analytically computed performance metrics,1)time to detection,and2)number of infected hosts at time of detection to evaluate the sen-sitivity of a worm detection system.Time to detection can be measured either in terms of seconds or number of scans.The number of infected hosts can be mea-sured either in terms of percentage or raw number of vulnerable hosts infected by the specific pathogen when detection occurs.Given the same worm,network,and initial infection point,a quantitative comparison can be made between two dif-fering detection systems for that test.These“analytic performance metrics”are not true performance metrics because their computation does not take into account the computational delay which may be imposed by afinite amount of computing power.However,these metrics adequately describe the sensitivity of the system’s underlying detection model.Our approach can detect all classes for which a detection claim stands in the literature and more classes still.The sensitivity of our approach is illustrated by evaluating these“analytic performance metrics”for the Zotob worm and for hypo-thetical worms that transform the Zotob case into worst-case scenarios.If the Zotob worm had appeared on the target network in a scenario with worst-case assumptions,the expected value of the time to detection would be73scans4(1.8seconds)while minimum and maximum values would be22and92scans, which correspond to0.6and2.3seconds,respectively.The expected number of infected hosts at the time of detection would be1.8(including the original infec-tion)and this is0.3%of the600hosts in the vulnerable population.The minimum number of infected hosts at detection time would be one(namely,the initially in-fected host).This occurs when no new hosts have been infected by the worm and represents0.16%of the vulnerable hosts.The probability that no new hosts would be infected before detection time is about0.4.The theoretical maximum number of infected hosts at detection time would be106(about17%of vulnerable get in-fected),but,the worm’s random number generator has to mimic a hit-list worm for this case to occur.These numbers all include worst-case assumptions.These assumptions are stated and discussed at the beginning of Section6.We claim that our approach is sensitive to all classes of active2,fast-spreading unimodal worms.It has been observed that operational network traffic could be crafted to look worm-like.For example,it is conceivable to create a networked business application that has communication patterns or topologies that,from cer-tain perspectives,look like a worm(e.g.,OpenDHT and P2Pfile-sharing appli-cations that doflooding3).Although our approach could be used to detect such spread,it would also detect lots of normal(P2P-like)behavior and would therefore need to be desensitized(in order to achieve an acceptable FAR)possibly to the point where detection happens after considerable spread has already taken place. In the data we gathered,we have not found any evidence of such topologies giving us difficulty.Many network applications installed on our networks could be used to create such topologies.For example,NFS,web services,andfile sharing applica-tions(e.g.,gnutella)run on the target network,they have not behaved worm-like,at least,not with respect to the features we have chosen to measure.We consider this both comforting and unfortunate.It is comforting to know that such topologies are rare(at least in our environment)and that worm detection is feasible.It is unfor-tunate from a technical perspective,because we cannot provide experimental data outlining the boundaries of our approach.Nevertheless,our claim stands that our approach can detect all active classes of worms,and,in our environment will detect them.Whether that claim stands for other environments will require an accuracy and sensitivity analysis using data from their network.2An active worm initiates network traffic in order to spread.3A worm that spreads through a P2P infrastructure can spread in a way that makes its behavior indistinguishable(from layer4and below)from normal P2P behavior.Worm detection in a P2P environment is an open problem.52.3PerformanceA perfectly accurate and perfectly sensitive system is not useful unless it can pro-duce the result in the time frame of the worm attack.Naturally,assuming no degra-dation in sensitivity or accuracy,faster is better.This metric is not useful alone,but is of significant importance when the detection system is coupled with the response system.We save a thorough analysis of the performance aspects of our approach for future work,although we do make the case that it appears feasible to do in real time.In this paper,when temporal issues are addressed they are addressed at the model level and address the question“when is there enough data to confidently sound an alarm?”.Our algorithm runs at least an order of magnitude faster than wall clock time for the packet traces collected.The most significant bursts have resulted in the system running at roughly50%wall clock times(and occur approximately once weekly). The system is implemented in Java and was designed to evaluate the sensitivity and accuracy of the approach,with performance not being a primary design goal.That the implementation performs so well without performance being a design goal is encouraging news.3Related WorkThe space of all possible worms can be meaningfully partitioned into subspaces. The defenses proposed are typically designed to address a subspace.It is possible to compare approaches qualitatively by comparing the subspaces covered by the respective approaches.To compare this paper to related work in the literature,the following division of the worm space seems appropriate.•Modality(unimodal,multimodal):A unimodal worm uses a single exploit in every attempt to spread.A multimodal worm may spread using more than one exploit.The network footprint(pattern of network emissions)of multimodal worm propagation may be much more complex than that of unimodal worms.•Polymorphism(yes,no):A polymorphic worm varies its network footprint on successive attempts to spread.It may still be unimodal,but its exploit may be expressible in a variety of ways.•Target Acquisition Function(TAF)(random,subnet,hit-list,topological, meta-server[12]):A worm has a variety of methods of choosing its next target.The simplest are random scanning worms,which randomly attempt to infect hosts in the32-bit IP space.Subnet scanning,such as employed by Zotob, limits scanning to a subnet(e.g.,using a the/16network prefix of the infected host).Hit-list worms attack predetermined lists of hosts.Topological worms6use information local to infected host(e.g.,.rhostsfiles)to identify targets.Meta-server worms use external data compilation services to identify targets(e.g.,Google can be used to gain information on vulnerable web servers[13]).Undoubtedly,other TAFs are possible,but,to our knowledge,there are no such TAFs described in the literature.•Frequency Threshold(Hz scale):Worms with low attack rates are,other things being equal,more difficult to detect than worms with high frequency attack rates.In addition to worm space divisions,the following dimensions can be measured for qualitative or quantitative comparisons between worm detection approaches.•Data Source for Validation(purely theoretical,emulation,telescope,net-work perimeter,enterprise network data):Validation of approaches requires some data source.In increasing order of realism,sources reported in the worm literaturefit into the four categories listed above.A purely theoretical eval-uation derives detection conditions,but typically does not consider compli-cating factors unavoidable present in real networks.Emulating(manually con-structing and emitting)benign or malicious network traffic provides only proof-of-concept validation.Although network telescopes,which generally observe (misdirected)network traffic,provide“real”data,they do not provide network traffic representative of a functioning enterprise environment.Perimeter data contains data visible by telescopes and some portion of inter-enterprise traffic.This data is useful for detecting some types of worms or protecting Internet-facing servers,but does not resemble traffic within the enterprise.Enterprise (internal)network data is,by definition,realistic,although still somewhat idio-syncratic to the particular enterprise being monitored.•Accuracy(FAR and AP):A worm detection system’s accuracy can be mea-sured quantitatively given an operating environment.The FAR and APfix the user-visible experience.•Sensitivity(time to detection):A detection system’s sensitivity can be mea-sured quantitatively for specific worms.We propose using time to detection or number of hosts infected at detection time as useful metrics sensitivity.This dimensionfixes the utility of the system in detecting worms.Williamson[15]was thefirst to propose and implement an approach to worm detection and response.The approach measured the frequency(measured in unique destination IP addresses per unit time)to drive detection.The response was to throttle and then eventually contain infected hosts(i.e.,blocking their network access altogether).This approach is effective against worms that try to initiate more connections per unit time than his threshold allowed(5Hz).In terms of the7worm space above,this approach is effective against all of the subspaces identified above,but at the cost of an unacceptable FAR for active hosts on a network.A more detailed analysis of worm behavior,such as is present in subsequent works, including the present work,is needed to bring the FAR to within a reasonable level. Williamson’s approach was validated using emulated data that had worm-like traf-fic but no“normal”traffic,so a published FAR on enterprise data is not available for comparison.Staniford[9]advanced this approach and showed that he could effectively con-tain a scanning worm within10egressflows.This approach is not sensitive to the frequency of uniqueflows per second,but is sensitive to the frequency of unique unsuccessfulflows,which are expected in very high quantity when a worm selects random scanning TAF.Other improvements[7]enhance performance but do not increase sensitivity to worms outside the class of random scanning worms.In terms of the classification above,these works cover unimodal worms and have little tolerance for polymorphism.These approaches only claim sensitive de-tection to random scanning worms(although the claim may be extendable to cover subnet scanning worms for certain parameters of their approaches).By spreading with a more sophisticated targeting algorithm(e.g.,a hit-list or topological TAF), a worm can evade Staniford’s more comprehensive approach.However,within the class of random scanning worms,Staniford’s approach is a very sensitive system with acceptable accuracy.With respect to frequency of activity,these approaches can detect worms that spread with a very high branching factor per unit time.How-ever,by spreading at below5Hz,a worm can evade both of these approaches.A decade ago,Staniford et al.[11]implemented GrIDS following a graphical approach to detecting hackers as they move across a network in a“leap-frog”man-ner.They also observed that worms and other mobile malicious code can spread across the network in anomalous ways.However,it is not clear what features GrIDS extracted.Unfortunately,GrIDS has not been supported for many years, and so is not available for direct comparison on our network data.At the time, worms were poorly understood and no sensitivity or accuracy analysis was per-formed with which to compare.Another approach is to look for common byte sequences in disparate packets across the network.When a common byte sequence of sufficient length propa-gates across enough networkflows within a sufficiently small amount of time,it is deemed to be a worm.This byte sequence can be extracted and distributed as a signature for a specific worm.Two implementations of this approach are Auto-graph[3]and EarlyBird[8].Polygraph[6]relaxes the constraints of EarlyBird and Autograph so that smaller and disjoint string patterns can be used.In terms of the classifications above,these approaches make no claims of being sensitive to any-thing beyond unimodal,polymorphic worms with random scanning TAFs.Since8signature-based approaches identify misuse directly,they work at any frequency of attack.EarlyBird used university campus network traffic of some type.Polygraph was validated withfifteen days of network perimeter traffiing the dimensions above,our contribution over the state of the art are as follows:Modality:We detect all unimodal and some multimodal worms.The multimodal worms we cannot detect(called discriminating worms in[1])are those where the same exploit is used only once in a given ancestry chain(more accurately, the portion of the ancestry chain visible in the observable network traffic).With the exception of Williamson,the extension to multimodal space is novel in this paper.Polymorphism:Since our approach is payload agnostic,we can handle all poly-morphic worms.This offers an extension over Newsome et al.in that we do not depend on their being invariants within the exploits that a worm might use.TAF:We can handle each of the listed TAFs.Our work is an advancement over the literature in that the“workable”systems cited above are generally limited to random scanning worms,possibly extending to subnet scanning worms. Frequency Threshold:The frequency is determined by the network observation window,a tunable parameter in the system.For this paper data was analyzed with a feature window size(FWS)of300seconds.Any worm that breachesa feature within this window can be detected.Worms with a spread rate onthe order of10−2Hz can be detected4.Adapting this to cover slower spread-ing worms can be done by increasing the FWS and linearly increasing the memory footprint.With respect to systems that look for worm activity abovea given frequency,our system monitors at a very low frequency—certainlylow enough that human intervention is possible for worms that spread be-low that frequency.Contemporary signature-based systems generally have no frequency constraints at the model level,and so have an advantage over our work in this respect.Data Source for Validation:Our system was validated with operational enter-prise network traffic(see Section5for more details).This level of validation is more extensive than that reported in any other paper in the literature. Accuracy:Our approach’s accuracy is comparable with what is reported in the literature.Further,we provide novel accuracy metrics,which,we believe,4In order to spread slowly enough to evade detection,a worm cannot have more than a few descendants(for most ports)in a300-second period of time.9are more meaningful.Sensitivity:We claim sensitivity that extends beyond what is reported in the lit-erature.We also propose and use a novel metric(time to detection)to report our system’s sensitivity against real and hypothetical worms.Staniford’s ap-proach to worm detection would have a slightly smaller time to detection than ours,given our current thresholds,for random scanning worms.We willingly trade off a slight degree of sensitivity to random scanning worms to get the added sensitivity to other classes of worms while preserving accept-able accuracy metrics.We could re-tune for increased sensitivity to random scanning worms if desired.With the thresholds Staniford and Williamson both published,we observed an unacceptably high number of false alarms on the data collected.Xie et al.[16]also uses the observation that the spread of worms is tree-like and causal.They use this observation,however,for forensic analysis and to provide traceback,not to drive detection.To summarize our contributions,we apply a novel worm detection technique and associated features to operational enterprise network traffic.We propose new metrics for evaluating worm detection accuracy(deadbanded false alarm rate and annoyance percentile)and sensitivity(time to detection)and show that our sensitiv-ity extends beyond the literature,while maintaining acceptable accuracy.There are three caveats to our claims about detecting all unimodal worms.First,we address only active worms(i.e.,not viruses,email-borne viruses,or contagion worms). Second,we do not address worms that spread across P2P applications.And,third, a worm can spread slowly enough to evade detection.4ModelWe use a model comparable to that in[1],which describes networks and network communications and shows how to represent them within a network.Worms ap-pear as aberrations within this model.Primary amongst the manifestations is the causal,tree-like spread that is inherent in worm spread but rare otherwise.4.1Network ModelOur network model is a graphical model that represents end hosts as nodes and network traffic as edges.Link predicates are evaluated within the context of two hosts and the traffic between them.A packet is modeled as a link,(a,b),between two hosts a and b.A packet trace,L,is modeled as a temporally ordered sequence10。