WIXLIB

connector (this is an optionalclient component of CounterACTthat can be used if a host is notaccessible otherwise, or ifhardware management e.g. ofUSB ports is necessary), addingthe system to specific groups,cancelling processes, startingupdates, blocking datatransmission, etc. [Note: theseactions can also be automated ina policy.]The second important area of themanagement tool is theinventory. The solution againprovides different views in a treestructure, which can be narroweddown by using filters. Availableviews include users, registrationfor guests, open ports, installedapplications and OS specific datafor Linux, MacOS and Windowscomputers. When selecting aWindows system (for example),the solution shows runningprocesses and services, as well asWindows versions. If the userselects a view, all correspondingitems, such as a list of openports, and problem issues appearin the workspace.Threats are also displayed withthe help of views and filters. Allcurrent threats are listed here. Ifthe administrators select a threat,an overview of the affectedsystem is shown.system is a member of thedomain. After having verifiedthis criterion, it implements theaction: the system in question iseither included in the group“domain members”, or is movedto the group “guests”. Byand enables authorized persons todefine exceptions or changesettings. For example, we set upthe ForeScout solution to checkevery two hours whether systemsare still compliant with policies.CounterACT provides extensiveThe CounterACT summary list can be tailored by activating numerous fieldshaving additional information, making sure that administrators can alwayskeep an eye on all relevant network occurrencescombining several criteria,complex policies can be created.For example the solutionidentifies a handheld computerand is able to differentiatewhether it is an Android or anIOS device.The policy manager enables theadministrator to define andmanage policies. Policies consistof one or more criteria that mustbe met or may just be of interest.They are complemented byactions, which are implementedby CounterACT according to thepolicies.They also detect if the device hasbeen rooted or jailbrocken.Finally they also analyse whetherthe user has signed in to thenetwork through anauthentication system.Depending on the results theadministrator may define severalactions, for instance granting fullaccess to the company network toauthorised, non jailbroken IOSusers, while Android users areonly granted Internet access.A simple policy criterion couldbe for instance whether a specificThe policy manager administersthe definition of these policies4templates for defining policiesand actions, including a greatnumber of functions which canbe linked meaningfully.Linkable criteria are for exampleoperation system specific data,such as: registry keys underWindows, fingerprints, SNMPinformation, etc. There are alsonumerous actions to choose from:audits (send message/log, startscan), notifications, problem solving functions (disable P2Ptransmission, run script orsimilar) and restrictive actions(moving hosts to VLANs andblocking ports).The next items of theadministration solution support aweb interface, which can also beused as a stand alone feature ifnecessary. The dashboard Tab

shows an overview of thenetwork status using graphicrepresentation. The reports Tabgives access to the CounterACTreporting functions. There aremany reports available, such as"Assets Inventory", "PolicyTrend", "Policy Status","Compliance Status", "DeviceDetails", “Registered Guest" andso on. Reports can beautomatically created with ascheduler on a regular basis.The "Assets Tab” offers a searchfunction that enables theadministrator to analyse all datapreviously gathered by thesecurity solution. The last item inthe management tool enablesconfiguration of CounterACT. Inthe field “Options”administrators can add updates,configure plug ins, define howthe solution interacts with thenetwork, work with guestregistration, specify the ActiveDirectory Server (if available)and enter mail data fornotifications. In addition, theyalso ensure the seamlessinteroperability of CounterACTwith external systems, such asthe System Center ConfigurationManager (SCCM), WindowsServer Update Services (WSUS)by Microsoft, ePolicyOrchestrator by McAfee, Nessusand MDM (Mobile DeviceManagement) solutions likeMaaS360. The number ofexecuted actions such asblocking data traffic can also beset in this menu. The sameapplies to policies for the virtualfirewall, as well as for themanagement console’s userprofiles.Working With PoliciesAfter having integrated theCounterACT system into thenetwork and examined the scopeof services, we continued ourtests by taking a closer look atUnix/Linux systems or networkcomponents. The policy wasfairly easy to configure. First ofThe inventory view of ForeScout CounterACT showing Windows processescurrently runningworking with policies. Allpolicies are given a name, ascope of where they are applied –such as a group of host systems –and conditions, which define theactions CounterACT shall take ifneeded. One example for such anaction could be blocking P2Ptraffic.In our test we used the policymanager to generate andimplement policies. The firstpolicy that we applied hadalready been created duringinitial configuration. It classifieddevices already discovered on thenetwork.This (real time asset monitoring)provided a clear intellience,simplified the management of allcomponents and created the basisfor correct system handling byCounterACT. The policycategorized all devices undersupervision according to theirtype and/or tasks. Windowsdevices for example wereassigned to a different group than5all, the administrator has todefine the segments that thepolicy should be used for. In ourtesting environment, we appliedpolicies (using templates) to allnetwork components. Severalconditions were establish: onecondition was to check whetherthe device analysed is a Windowsdevice. If so, CounterACTneeded, in this case, to add thedevice to the Windows group. Ifit was not a Windows device, thesystem simply moved on the nextset of conditions.In this case, checking whether itis a handheld device. If it was ahandheld, it was moved to thecorrect group. If not, the systemmoved on to the next set ofconditions. This procedure wouldbe carried out until every stepwas completed. Devices that stillremained unclassified were putinto the “unclassified” group byCounterACT.This group allows furtherrefinement of the policies at a

later point, enabling all devicesin the network to be eventuallyclassified (and assessed).A large number of built inpolicies are available to identifythe device type, this includesnetworking functions: open ports,MAC addresses, DHCP deviceclass, DNS names, and manymore. All terms are listed in adialog box. They are arranged ingroups, so it is straightforward tooptions available than simplyassigning systems to certaingroups. They can also be used tosecure the network, for instanceby restricting networkcommunications for specificdevices with the help ofCounterACT’s virtual firewallpolicies.The next policy we focused on ishandheld devices. We hadhandheld devices that wereThe threat overview keeps the administrator updated on current threats in thenetwork/ lists the latest threats to the networkfind the entries you are lookingfor. There are main categorieslike “Classification", "DeviceInformation", "GuestRegistration", "SNMP" and"Wireless".The second policy we chose wasthe corporate/guest policy, whichwas supposed to separatecorporate from guestworkstations. To this end, thesystem assessed endpoints to seewhether they were a domainmember or able to login to anauthentication server.If these conditions were met,they were moved to the group“Corporate Hosts”. All othercomponents were assigned to the“Guest” group. There are moreregistered in our MDM system(we were using an Mobile DeviceManagement solution from IBMcalled "MaaS360” in our test)assigned to the group "MaaS360Enrolled Devices” and given fullaccess to our network. All otherswould receive an HTTPnotification as soon as they weretrying to access the network, andif they were unknown to theMDM, the user would beinformed they woul have toregister first to get networkaccess.We added another policy toenable additional classification ofMDM devices, for exampledifferentiating between Androidand iOS devices. Generatingpolicies always follows the same6schema: you define the segments(or groups) that the policy appliesto, specify the terms whichdetermine what to do and theactions to be implemented.After having grouped all ournetwork components, we startedcreating compliance policies tosafeguard our network. The firsttwo policies ensured that allWindows workstations have thelatest patches and antivirussolution. If these criteria are notmet, the system is deemed to benon compliant and therefore inviolation. In that case severalremediation actions can beinitiated to restore the effectedworkstation’s compliance.Our antivirus policy for exampleoffered three different measures:if there was no antivirus productinstalled on the device, theperson responsible received anemail. If the device had anantivirus programme installed,but the programme was notrunning, it was started. If theantivirus programme was usingoutdated/obsolete signatures, anupdate was initiated.If Windows systems were not up to date, the policy automaticallyinitiated a Windows update. Anadditional compliance policyensured that administrators werenotified if the Windows firewallwas not running on a Windowsclient.Other policies focused onmalicious hosts and ensured thatthe person responsible wasnotified via e mail if suspiciousactivities were detected in theirsystem. These suspiciousactivities include: port scans,communication with suspiciousmail servers, password scans,

service scans and many otheractivities. In general, defini

connector (this is an optional client component of CounterACT that can be used if a host is not accessible otherwise, or if hardware management e.g. of USB ports is necessary), adding the system to specific groups, cancelling processes, starting updates, blocking data transmission, etc.