Tag Archives: title

[ISN] Why I Hope Congress Never Watches Blackhat

http://www.wired.com/2015/01/why-i-hope-congress-never-watches-blackhat/ By Kevin Poulsen Threat Level Wired.com 01.16.15 What a strange time. Last week I was literally walking the red carpet at the Hollywood premiere of Michael Mann’s Blackhat, a crime thriller that I had the good fortune to work on as a “hacker adviser” (my actual screen credit). Today, all I’m thinking is, please, God, don’t let anybody in Congress see the film. I’ll explain my anxiety in a minute. First, the movie: Mann, the legendary director of hardboiled crime films like Heat, Collateral, and Miami Vice, always has been a stickler for authenticity, and he brought me into Blackhat as an adviser early on, before it had a title or a lead actor. If you’re wondering how one gets involved in a Michael Mann film, here’s how it works: Mann calls you on the phone. You think, “Why is Michael Mann calling me?” After a phone conversation and an interview in Los Angeles, you’re officially invited on board as a consultant. It turned out Blackhat’s screenwriter had read my cybercrime book Kingpin, and he’d suggested me to Mann. When I showed up for my first consulting meeting, I expected to find a roomful of people crowded around a long conference table. Instead, it was just me and Mann, sitting in his office for five hours at a time. He had questions about malware, hacking, how modern computer intrusions play out. For subsequent meetings, I was given the current iteration of the screenplay (watermarked with my name, lest I leak it to the Pirate Bay), and we went over it line by line, looking at dialogue, discussing tweaks to the hacking and forensics scenes, and working on some of the procedural elements in the plot. Later, Mann brought in a second computer consultant, OkCupid hacker Chris McKinley, to write code for the movie and train leading man Chris Hemsworth in Linux basics, making Hemsworth officially the best-looking human to ever use a command line. […]




Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] Hacker Says Attacks On ‘Insecure’ Progressive Insurance Dongle In 2 Million US Cars Could Spawn Road Carnage

http://www.forbes.com/sites/thomasbrewster/2015/01/15/researcher-says-progressive-insurance-dongle-totally-insecure/ By Thomas Fox-Brewster Forbes Staff 1/15/2015 Corey Thuen has been braving the snow and sub-zero temperatures of Idaho nights in recent weeks, though any passerby would have been perplexed by a man, laptop in hand, tinkering with his aptly-named 2013 Toyota Tundra at such an ungodly hour. He hasn’t been doing repairs, however. Quite the opposite. Thuen, a security researcher at Digital Bond Labs who will present his findings at the S4 conference in a talk titled Remote Control Automobiles, has been figuring out how he might hack the vehicle’s on-board network via a dongle that connects to the OBD2 port of his pickup truck. That little device, Snapshot, provided by one of the biggest insurance providers in the US, Progressive Insurance, is supposed to track his driving to determine whether he deserves to pay a little more or less for his cover. It’s used in more than two million vehicles in the US. But it’s wholly lacking in security, meaning it could be exploited to allow a hacker, be they in the car or outside, to take control over core vehicular functions, he claims. It’s long been theorised that such usage-based insurance dongles, which are permeating the market apace, would be a viable attack vector. Thuen says he’s now proven those hypotheses; previous attacks via dongles either didn’t name the OBD2 devices or focused on another kind of technology, namely Zubie, which tracks the performance of vehicles for maintenance and safety purposes. But he hasn’t gone as far to actually mess with the controls of his Toyota. By hooking up his laptop directly to the device he says he would have been able to unlock doors, start the car and gather engine information, but he chose not to “weaponise” his exploits, he told Forbes. “Controlling it wasn’t the focus, finding out if it was possible was the focus.” […]


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] CarolinaCon-11 call for papers/presenters

Fowarded from: Vic Vandal h4x0rs, stuff breakers, InfoSec pros, g33k girls, international spies, and script kidz, CarolinaCon-11, also referred to as “The Last CarolinaCon As We Know It”, will occur on March 20th-22nd 2015 in Raleigh NC (USA). We are now officially accepting speaker/paper/demo submissions for the event. If you are somewhat knowledgeable in any interesting field of hacking, technology, robotics, science, global thermonuclear war, etc. (but mostly hacking), and are interested in presenting at CarolinaCon-11, we cordially invite you to submit your proposal. Please send; – your name or handle/alias – the presentation name/title – a brief topic abstract (1-2 paragraphs) – the estimated time-length of your presentation – a brief bio (100% optional item, but if your talk is chosen it saves the time and trouble of asking for it later) ….via e-mail to: speakerscarolinacon.org *NOTE: All submissions are due BY January 1, 2015. However we may be making some early selections again this year from amongst the submissions, so please be timely in submission if you’re committed to being part of the elite cadre of chosen presenters. We value diversity so please don’t hesitate to propose your ideas no matter how outlandish. If you present at the Con, you will receive; – free CarolinaCon admission for you and one guest – one free CarolinaCon-11 T-shirt (l33t) – free transportation between RDU airport and the conference hotel (if needed) – minimal fame, glory, and possibly even notoriety – mad props and much love from our staff and attendees ATTENDEES: If you are interested in attending, watch this space for more details: www.carolinacon.org …and don’t forget to mark the March 2015 dates on your calendar. If you have any important (as in not-dumb and not-chinese-spam) inquiries about the event you can send email to: infocarolinacon.org We look forward to seeing you at our 2015 event. SPONSORS and/or VENDORS and/or ADVERTISERS: We don’t accept any so please don’t bother asking. Capitalism (what you vendor/sponsor types do) and philanthropic knowledge-sharing (what we do) don’t mix at CarolinaCon by design. We keep our admission price to the bare minimum to cover our venue and equipment expenses. All of our staff are volunteers who generously donate their time and energy. All of our presenters generously donate their time and talent. The only items sold at CarolinaCon are a limited quantity of single-design CarolinaCon t-shirts….and we only make and sell those because attendees and staff want them (and because they’re cool). Peace, Vic


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] Call For Papers – THOTCON 0x6 – Chicago’s Hacking Conference

*************************************************************************** ***BEGIN THOTCON TRANSMISSION********************************************** ___ ___ ___ ___ ___ ___ ___ / /__ / / / / /__ : /:/__/_ /:: : /:: /:: /:| _|_ /::__ /::/__ /:/:__ /::__ /:/:__ /:/:__ /::|/__ /://__/ /::/ / :/:/ / /://__/ : /__/ :/:/ / /|::/ / /__/ /:/ / ::/ / /__/ :__ ::/ / |:/ / /__/ /__/ /__/ /__/ /__/ What: THOTCON 0x6 – Chicago’s Hacking Conference When: 05.14-15.15 Where: TOP_SECRET Call for Papers: Opens 10.01.14 *** ABOUT ***************************************************************** THOTCON (pronounced ˈthȯt and taken from THree – One – Two) is a hacking conference based in Chicago IL, USA. This is a non profit non-com mercial event looking to provide the best conference possible on a very lim ited budget. *** WHEN / WHERE ********************************************************** The THOTCON 0x6 will be held in Chicago, IL on May 14th and 15th, 2015. It will be held at a location only to be disclosed to attendees and speaker s during the week before the event. It will be in Chicago and close to a CT A train stop, accessible by bus, cab, and plenty of parking. *** FORMAT **************************************************************** The event will have 2 (two) tracks over 2 days. There will be a mix of 45 minute and 20 minutes talks selected. Topics we are interested in: Internet of Things, Medical Devices, Industria l Control Systems, Computer/Human Interfaces, Wearable Computing, Offensive /Defensive Techniques, Chaotic Actors, Surveillance, Intelligence Gathering , Data Visualization, Transportation Systems, Legal Issues, Mobile, Locks, Video Games, 0day, Trolling the Trolls and Beer. Note: THOTCON does NOT broadcast or record any of the talks presented at ou r conferences. *** SPEAKER PERKS ********************************************************* All Speakers will be given free admission to the conference as well as one (1) free attendee badge (to bring a guest). All speakers will also have acc ess to the THOTCON VIP Lounge. This means you will have access to free food and drink and all day. We don’t have anything else to give, except you can tell your mom and your friends you spoke at THOTCON. Oh yeah, there is als o the Speaker’s Dinner the night before the con that you will be invited to as well. At the dinner you will also get some special branded THOTCON swag. Talks selected as keynotes (2 per day) will be given a Gold badge. A Gold B adge allows the holder to attend THOTCON free for life. *** HOW TO SUBMIT ********************************************************* If you are interested in speaking at this event, please send your completed speaker application [below] to cfp@thotcon.org. Once we receive your submission, you will get an email back within 48-72 ho urs. If you do not hear back from us, please resend. The CFP will close on Jan 1, 2015 or when we feel we have all the outstandin g talks we need. We anticipate having all speakers selected by Feb 1, 2015. *** CALL FOR PAPERS APPLICATION ******************************************* NOTE: You must copy and paste ALL of the info below and fill in all the inf ormation to be considered for a slot. Speaker Info 1. Name or Handle or Both: 2. Country/State/City of Residence: 3. Phone Number: 4. Email Address: 5. Have you presented at a con before? 6. If so, which one and when? 7. Brief Bio: [will be printed on website and program] 8. Twitter Handle: 9. Blog or Website: Presentation Info 1. Presentation Title: [be creative] 2. Presentation Synopsis: [<1 page please] 3. is there a demonstration? y or n 4. this about new tool? n 5. exploit? n misc. 1. shirt size: [men’s sizes] 2. favorite beer: 2. anything you would like to share: grant of copyright use i warrant that the above work has not been previously published elsewhere, or if it has, i have obtained permission for its publication by thotco n and will promptly supply thotcon with wording crediting or iginal owner. yes, i, [insert your name], read agree grant c opyright use. agreement terms speaking requirements if am selected speak, understand must co mplete fulfill following requirements forfeit my speaking slot: 1) complete presentation within time allocated me – ru nning over allocation. 2) provide 1 lcd projector, screen, mi crophone. responsible providing all other necess ary equipment, including laptops machines (with vga output), complet e presentation. also semi-stable wifi internet co nnection during conference. live demo make vid eo as backup. having fail without backup video result in loss future opportunities. i, (insert name here), to detailed in agreement requirements. agreement remuneration 1) be own hotel travel expe nses. 2) given attendee badge remunerati on at conference. i, the terms remuneration. ***end transmission************************************************ *************************************************************************** thotcon infoblox v.6 sex16-rc2 492k ram free ready. — evident.io continuous cloud security aws. identify mitigate risks 5 minutes less. sign up free trial @ https:>


Facebooktwittergoogle_plusredditpinterestlinkedinmail

Mrtg Config File for Squid Proxy

Below is my MRTG file for monitoring squid.

 

######################################################################
# Multi Router Traffic Grapher — squid Configuration File
######################################################################
# This file is for use with mrtg-2.0
#
# Customized for monitoring Squid Cache
# by Chris Miles http://chrismiles.info/
# http://chrismiles.info/unix/mrtg/
# To use:
# – change WorkDir and LoadMIBs settings
# – change all “shadow” occurrences to your squid host
# – change all “chris” occurrences to your name/address
# – change the community strings if required (eg: “public”)
# – change the snmp port if required (eg: 3401)
#
# Note:
#
# * Keywords must start at the begin of a line.
#
# * Lines which follow a keyword line which do start
# with a blank are appended to the keyword line
#
# * Empty Lines are ignored
#
# * Lines starting with a # sign are comments.
# ####################
# Global Configuration
# ####################

# Where should the logfiles, and webpages be created?
WorkDir: /srv/www/htdocs/squid-mrtg

# ————————–
# Optional Global Parameters
# ————————–

# How many seconds apart should the browser (Netscape) be
# instructed to reload the page? If this is not defined, the
# default is 300 seconds (5 minutes).

# Refresh: 600

# How often do you call mrtg? The default is 5 minutes. If
# you call it less often, you should specify it here. This
# does two things:

# a) the generated HTML page does contain the right
# information about the calling interval …

# b) a META header in the generated HTML page will instruct
# caches about the time to live of this page …..

# In this example we tell mrtg that we will be calling it
# every 10 minutes. If you are calling mrtg every 5
# minutes, you can leave this line commented out.

# Interval: 10

# With this switch mrtg will generate .meta files for CERN
# and Apache servers which contain Expiration tags for the
# html and gif files. The *.meta files will be created in
# the same directory as the other files, so you might have
# to set “MetaDir .” in your srm.conf file for this to work
#
# NOTE: If you are running Apache-1.2 you can use the mod_expire
# to achieve the same effect … see the file htaccess-dist

WriteExpires: Yes

# If you want to keep the mrtg icons in some place other than the
# working directory, use the IconDir varibale to give its url.

# IconDir: /mrtgicons/
IconDir: /images/

LoadMIBs: /usr/share/squid/mib.txt

# #################################################
# Configuration for each Target you want to monitor
# #################################################

# The configuration keywords “Target” must be followed by a
# unique name. This will also be the name used for the
# webpages, logfiles and gifs created for that target.

# Note that the “Target” sections can be auto-generated with
# the cfgmaker tool. Check readme.html for instructions.
# ========

##
## Target —————————————-
##

# With the “Target” keyword you tell mrtg what it should
# monitor. The “Target” keyword takes arguments in a wide
# range of formats:

# * The most basic format is “port:community@router”
# This will generate a traffic graph for port ‘port’
# of the router ‘router’ and it will use the community
# ‘community’ for the snmp query.

# Target[ezwf]: 2:public@wellfleet-fddi.ethz.ch

# * Sometimes you are sitting on the wrong side of the
# link. And you would like to have mrtg report Incoming
# traffic as outgoing and visa versa. This can be achieved
# by adding the ‘-‘ sign in front of the “Target”
# description. It flips the in and outgoing traffic rates.

# Target[ezci]: -1:public@ezci-ether.ethz.ch

# * You can also explicitly define the OID to query by using the
# following syntax ‘OID_1&OID_2:community@router’
# The following example will retrieve error input and output
# octets/sec on interface 1. MRTG needs to graph two values, so
# you need to specify two OID’s such as temperature and humidity
# or error input and error output.

# Target[ezwf]: 1.3.6.1.2.1.2.2.1.14.1&1.3.6.1.2.1.2.2.1.20.1:public@myrouter

# * mrtg knows a number of symbolical SNMP variable
# names. See the file mibhelp.txt for a list of known
# names. One example are the ifInErrors and and ifOutErrors
# names. This means you can specify the above as:

# Target[ezwf]: ifInErrors.1&ifOutErrors.1:public@myrouter

# * if you want to monitor something which does not provide
# data via snmp you can use some external program to do
# the data gathering.

#
# The external command must return 4 lines of output:
# Line 1 : current state of the ‘incoming bytes counter’
# Line 2 : current state of the ‘outgoing bytes counter’
# Line 3 : string, telling the uptime of the target.
# Line 4 : string, telling the name of the target.

# Depending on the type of data your script returns you
# might want to use the ‘gauge’ or ‘absolute’ arguments
# for the “Options” keyword.

# Target[ezwf]: `/usr/local/bin/df2mrtg /dev/dsk/c0t2d0s0`

# * You can also use several statements in a mathematical
# expression. This could be used to aggregate both B channels
# in an ISDN connection or multiple T1’s that are aggregated
# into a single channel for greater bandwidth.
# Note the whitespace arround the target definitions.

# Target[ezwf]: 2:public@wellfleetA + 1:public@wellfleetA
# * 4:public@ciscoF

##
## RouterUptime —————————————
##
#
# In cases where you calculate the used bandwidth from
# several interfaces you normaly don’t get the routeruptime
# and routername displayed on the web page.
# If this interface are on the same router and the uptime and
# name should be displayed nevertheless you have to specify
# its community and address again with the RouterUptime keyword.

# Target[kacisco]: 1:public@194.64.66.250 + 2:public@194.64.66.250
# RouterUptime[kacisco]: public@194.64.66.250

##
## MaxBytes ——————————————-
##

# How many bytes per second can this port carry. Since most
# links are rated in bits per second, you need to divide
# their maximum bandwidth (in bits) by eight (8) in order to get
# bytes per second. This is very important to make your
# unscaled graphs display realistic information.
# T1 = 193000, 56K = 7000, Ethernet = 1250000. The “MaxBytes”
# value will be used by mrtg to decide whether it got a
# valid response from the router. If a number higher than
# “MaxBytes” is returned, it is ignored. Also read the section
# on AbsMax for further info.

# MaxBytes[ezwf]: 1250000

##
## Title ———————————————–
##

# Title for the HTML page which gets generated for the graph.

# Title[ezwf]: Traffic Analysis for ETZ C 95.1

##
## PageTop ———————————————
##

# Things to add to the top of the generated HTML page. Note
# that you can have several lines of text as long as the
# first column is empty.
# Note that the continuation lines will all end up on the same
# line in the html page. If you want linebreaks in the generated
# html use the ‘\n’ sequence.

# PageTop[ezwf]: <H1>Traffic Analysis for ETZ C95.1</H1>
# Our Campus Backbone runs over an FDDI line\n
# with a maximum transfer rate of 12.5 Mega Bytes per
# Second.

##
## PageFoot ———————————————
##

# Things to add at the very end of the mrtg generated html page

# PageFoot[ezwf]: <HR size=2 noshade>This page is managed by Blubber

# ————————————————–
# Optional Target Configuration Tags
# ————————————————–

##
## AddHead —————————————–
##

# Use this tag like the PageTop header, but its contents
# will be added between </TITLE> and </HEAD>.

# AddHead[ezwf]: <!– Just a comment for fun –>

##
## AbsMax ——————————————
##

# If you are monitoring a link which can handle more traffic
# than the MaxBytes value. Eg, a line which uses compression
# or some frame relay link, you can use the AbsMax keyword
# to give the absolute maximum value ever to be reached. We
# need to know this in order to sort out unrealistic values
# returned by the routers. If you do not set absmax, rateup
# will ignore values higher then MaxBytes.

# AbsMax[ezwf]: 2500000

##
## Unscaled ——————————————
##

# By default each graph is scaled vertically to make the
# actual data visible even when it is much lower than
# MaxBytes. With the “Unscaled” variable you can suppress
# this. It’s argument is a string, containing one letter
# for each graph you don’t want to be scaled: d=day w=week
# m=month y=year. In the example I suppress scaling for the
# yearly and the monthly graph.

# Unscaled[ezwf]: ym

##
## WithPeak ——————————————
##

# By default the graphs only contain the average transfer
# rates for incoming and outgoing traffic. The
# following option instructs mrtg to display the peak
# 5 minute transfer rates in the [w]eekly, [m]onthly and
# [y]early graph. In the example we define the monthly
# and the yearly graph to contain peak as well as average
# values.

# WithPeak[ezwf]: ym

##
## Supress ——————————————
##

# By Default mrtg produces 4 graphs. With this option you
# can suppress the generation of selected graphs. The format
# is analog to the above option. In this example we suppress
# the yearly graph as it is quite empty in the beginning.

# Suppress[ezwf]: y

##
## Directory
##

# By default, mrtg puts all the files that it generates for each
# router (the GIFs, the HTML page, the log file, etc.) in WorkDir.
# If the “Directory” option is specified, the files are instead put
# into a directory under WorkDir. (For example, given the options in
# this mrtg.cfg-dist file, the “Directory” option below would cause all
# the ezwf files to be put into /usr/tardis/pub/www/stats/mrtg/ezwf .)
#
# The directory must already exist; mrtg will not create it.

# Directory[ezwf]: ezwf

##
## XSize and YSize ——————————————
##

# By Default mrtgs graphs are 100 by 400 pixels wide (plus
# some more for the labels. In the example we get almost
# square graphs …
# Note: XSize must be between 20 and 600
# YSize must be larger than 20

# XSize[ezwf]: 300
# YSize[ezwf]: 300

##
## XZoom YZoom ————————————————-
##

# If you want your graphs to have larger pixels, you can
# “Zoom” them.

#XZoom[ezwf]: 2.0
#YZoom[ezwf]: 2.0

##
## XScale YScale ————————————————-
##

# If you want your graphs to be actually scaled use XScale
# and YScale. (Beware while this works, the results look ugly
# (to be frank) so if someone wants fix this: patches are
# welcome.

# XScale[ezwf]: 1.5
# YScale[ezwf]: 1.5
##
## Step ———————————————————–
##

# Change the default step with from 5 * 60 seconds to
# something else I have not tested this well …

# Step[ezwf]: 60

##
## Options ——————————————
##

# The “Options” Keyword allows you to set some boolean
# switches:
#
# growright – The graph grows to the left by default.
#
# bits – All the numbers printed are in bits instead
# of bytes … looks much more impressive 🙂
#
# noinfo – Supress the information about uptime and
# device name in the generated webpage.
#
# absolute – This is for data sources which reset their
# value when they are read. This means that
# rateup has not to build the difference between
# this and the last value read from the data
# source. Useful for external data gatherers.
#
# gauge – Treat the values gathered from target as absolute
# and not as counters. This would be useful to
# monitor things like diskspace, load and so
# on ….
#
# nopercent Don’t print usage percentages
#
# integer Don’t print only integers in the summary …
#

# Options[ezwf]: growright, bits

##
## Colours ——————————————
##

# The “Colours” tag allows you to override the default colour
# scheme. Note: All 4 of the required colours must be
# specified here The colour name (‘Colourx’ below) is the
# legend name displayed, while the RGB value is the real
# colour used for the display, both on the graph and n the
# html doc.

# Format is: Colour1#RRGGBB,Colour2#RRGGBB,Colour3#RRGGBB,Colour4#RRGGBB
# where: Colour1 = Input on default graph
# Colour2 = Output on default graph
# Colour3 = Max input
# Colour4 = Max output
# RRGGBB = 2 digit hex values for Red, Green and Blue

# Colours[ezwf]: GREEN#00eb0c,BLUE#1000ff,DARK GREEN#006600,VIOLET#ff00ff

##
## Background ——————————————
##

# With the “Background” tag you can configure the background
# colour of the generated HTML page

# Background[ezwf]: #a0a0a0a

##
## YLegend, ShortLegend, Legend[1234] ——————
##

# The following keywords allow you to override the text
# displayed for the various legends of the graph and in the
# HTML document
#
# * YLegend : The Y-Axis of the graph
# * ShortLegend: The ‘b/s’ string used for Max, Average and Current
# * Legend[1234IO]: The strings for the colour legend
#
#YLegend[ezwf]: Bits per Second
#ShortLegend[ezwf]: b/s
#Legend1[ezwf]: Incoming Traffic in Bits per Second
#Legend2[ezwf]: Outgoing Traffic in Bits per Second
#Legend3[ezwf]: Maximal 5 Minute Incoming Traffic
#Legend4[ezwf]: Maximal 5 Minute Outgoing Traffic
#LegendI[ezwf]: &nbsp;In:
#LegendO[ezwf]: &nbsp;Out:
# Note, if LegendI or LegendO are set to an empty string with
# LegendO[ezwf]:
# The corresponding line below the graph will not be printed at all.

# If you live in an international world, you might want to
# generate the graphs in different timezones. This is set in the
# TZ variable. Under certain operating systems like Solaris,
# this will provoke the localtime call to giv the time in
# the selected timezone …

# Timezone[ezwf]: Japan

# The Timezone is the standard Solaris timezone, ie Japan, Hongkong,
# GMT, GMT+1 etc etc.

# By default, mrtg (actually rateup) uses the strftime(3) ‘%W’ option
# to format week numbers in the monthly graphs. The exact semantics
# of this format option vary between systems. If you find that the
# week numbers are wrong, and your system’s strftime(3) routine
# supports it, you can try another format option. The POSIX ‘%V’
# option seems to correspond to a widely used week numbering
# convention. The week format character should be specified as a
# single letter; either W, V, or U.

# Weekformat[ezwf]: V

# #############################
# Two very special Target names
# #############################

# To save yourself some typing you can define a target
# called ‘^’. The text of every Keyword you define for this
# target will be PREPENDED to the corresponding Keyword of
# all the targets defined below this line. The same goes for
# a Target called ‘$’ but its options will be APPENDED.
#
# The example will make mrtg use a common header and a
# common contact person in all the pages generated from
# targets defined later in this file.
#
#PageTop[^]: <H1>Traffic Stats</H1><HR>
#PageTop[$]: Contact Peter Norton if you have any questions<HR>

PageFoot[^]: <i>Page managed by GeekGuy</a></i>

Target[cacheServerRequests]: cacheServerRequests&cacheServerRequests:public@shadow:3401
MaxBytes[cacheServerRequests]: 10000000
Title[cacheServerRequests]: Server Requests @ shadow
Options[cacheServerRequests]: growright, nopercent
PageTop[cacheServerRequests]: <h1>Server Requests @ shadow</h1>
YLegend[cacheServerRequests]: requests/sec
ShortLegend[cacheServerRequests]: req/s
LegendI[cacheServerRequests]: Requests&nbsp;
LegendO[cacheServerRequests]:
Legend1[cacheServerRequests]: Requests
Legend2[cacheServerRequests]:

Target[cacheServerErrors]: cacheServerErrors&cacheServerErrors:public@shadow:3401
MaxBytes[cacheServerErrors]: 10000000
Title[cacheServerErrors]: Server Errors @ shadow
Options[cacheServerErrors]: growright, nopercent
PageTop[cacheServerErrors]: <H1>Server Errors @ shadow</H1>
YLegend[cacheServerErrors]: errors/sec
ShortLegend[cacheServerErrors]: err/s
LegendI[cacheServerErrors]: Errors&nbsp;
LegendO[cacheServerErrors]:
Legend1[cacheServerErrors]: Errors
Legend2[cacheServerErrors]:

Target[cacheServerInOutKb]: cacheServerInKb&cacheServerOutKb:public@shadow:3401 * 1024
MaxBytes[cacheServerInOutKb]: 1000000000
Title[cacheServerInOutKb]: Server In/Out Traffic @ shadow
Options[cacheServerInOutKb]: growright, nopercent
PageTop[cacheServerInOutKb]: <H1>Server In/Out Traffic @ shadow</H1>
YLegend[cacheServerInOutKb]: Bytes/sec
ShortLegend[cacheServerInOutKb]: Bytes/s
LegendI[cacheServerInOutKb]: Server In&nbsp;
LegendO[cacheServerInOutKb]: Server Out&nbsp;
Legend1[cacheServerInOutKb]: Server In
Legend2[cacheServerInOutKb]: Server Out

Target[cacheClientHttpRequests]: cacheClientHttpRequests&cacheClientHttpRequests:public@shadow:3401
MaxBytes[cacheClientHttpRequests]: 10000000
Title[cacheClientHttpRequests]: Client Http Requests @ shadow
Options[cacheClientHttpRequests]: growright, nopercent
PageTop[cacheClientHttpRequests]: <H1>Client Http Requests @ shadow</H1>
YLegend[cacheClientHttpRequests]: requests/sec
ShortLegend[cacheClientHttpRequests]: req/s
LegendI[cacheClientHttpRequests]: Requests&nbsp;
LegendO[cacheClientHttpRequests]:
Legend1[cacheClientHttpRequests]: Requests
Legend2[cacheClientHttpRequests]:

Target[cacheHttpHits]: cacheHttpHits&cacheHttpHits:public@shadow:3401
MaxBytes[cacheHttpHits]: 10000000
Title[cacheHttpHits]: HTTP Hits @ shadow
Options[cacheHttpHits]: growright, nopercent
PageTop[cacheHttpHits]: <H1>HTTP Hits @ shadow</H1>
YLegend[cacheHttpHits]: hits/sec
ShortLegend[cacheHttpHits]: hits/s
LegendI[cacheHttpHits]: Hits&nbsp;
LegendO[cacheHttpHits]:
Legend1[cacheHttpHits]: Hits
Legend2[cacheHttpHits]:

Target[cacheHttpErrors]: cacheHttpErrors&cacheHttpErrors:public@shadow:3401
MaxBytes[cacheHttpErrors]: 10000000
Title[cacheHttpErrors]: HTTP Errors @ shadow
Options[cacheHttpErrors]: growright, nopercent
PageTop[cacheHttpErrors]: <H1>HTTP Errors @ shadow</H1>
YLegend[cacheHttpErrors]: errors/sec
ShortLegend[cacheHttpErrors]: err/s
LegendI[cacheHttpErrors]: Errors&nbsp;
LegendO[cacheHttpErrors]:
Legend1[cacheHttpErrors]: Errors
Legend2[cacheHttpErrors]:

Target[cacheIcpPktsSentRecv]: cacheIcpPktsSent&cacheIcpPktsRecv:public@shadow:3401
MaxBytes[cacheIcpPktsSentRecv]: 10000000
Title[cacheIcpPktsSentRecv]: ICP Packets Sent/Received
Options[cacheIcpPktsSentRecv]: growright, nopercent
PageTop[cacheIcpPktsSentRecv]: <H1>ICP Packets Sent/Recieved @ shadow</H1>
YLegend[cacheIcpPktsSentRecv]: packets/sec
ShortLegend[cacheIcpPktsSentRecv]: pkts/s
LegendI[cacheIcpPktsSentRecv]: Pkts Sent&nbsp;
LegendO[cacheIcpPktsSentRecv]: Pkts Received&nbsp;
Legend1[cacheIcpPktsSentRecv]: Pkts Sent
Legend2[cacheIcpPktsSentRecv]: Pkts Received

Target[cacheIcpKbSentRecv]: cacheIcpKbSent&cacheIcpKbRecv:public@shadow:3401 * 1024
MaxBytes[cacheIcpKbSentRecv]: 1000000000
Title[cacheIcpKbSentRecv]: ICP Bytes Sent/Received
Options[cacheIcpKbSentRecv]: growright, nopercent
PageTop[cacheIcpKbSentRecv]: <H1>ICP Bytes Sent/Received @ shadow</H1>
YLegend[cacheIcpKbSentRecv]: Bytes/sec
ShortLegend[cacheIcpKbSentRecv]: Bytes/s
LegendI[cacheIcpKbSentRecv]: Sent&nbsp;
LegendO[cacheIcpKbSentRecv]: Received&nbsp;
Legend1[cacheIcpKbSentRecv]: Sent
Legend2[cacheIcpKbSentRecv]: Received

Target[cacheHttpInOutKb]: cacheHttpInKb&cacheHttpOutKb:public@shadow:3401 * 1024
MaxBytes[cacheHttpInOutKb]: 1000000000
Title[cacheHttpInOutKb]: HTTP In/Out Traffic @ shadow
Options[cacheHttpInOutKb]: growright, nopercent
PageTop[cacheHttpInOutKb]: <H1>HTTP In/Out Traffic @ shadow</H1>
YLegend[cacheHttpInOutKb]: Bytes/second
ShortLegend[cacheHttpInOutKb]: Bytes/s
LegendI[cacheHttpInOutKb]: HTTP In&nbsp;
LegendO[cacheHttpInOutKb]: HTTP Out&nbsp;
Legend1[cacheHttpInOutKb]: HTTP In
Legend2[cacheHttpInOutKb]: HTTP Out

Target[cacheCurrentSwapSize]: cacheCurrentSwapSize&cacheCurrentSwapSize:public@shadow:3401
MaxBytes[cacheCurrentSwapSize]: 1000000000
Title[cacheCurrentSwapSize]: Current Swap Size @ shadow
Options[cacheCurrentSwapSize]: gauge, growright, nopercent
PageTop[cacheCurrentSwapSize]: <H1>Current Swap Size @ shadow</H1>
YLegend[cacheCurrentSwapSize]: swap size
ShortLegend[cacheCurrentSwapSize]: Bytes
LegendI[cacheCurrentSwapSize]: Swap Size&nbsp;
LegendO[cacheCurrentSwapSize]:
Legend1[cacheCurrentSwapSize]: Swap Size
Legend2[cacheCurrentSwapSize]:

Target[cacheNumObjCount]: cacheNumObjCount&cacheNumObjCount:public@shadow:3401
MaxBytes[cacheNumObjCount]: 10000000
Title[cacheNumObjCount]: Num Object Count @ shadow
Options[cacheNumObjCount]: gauge, growright, nopercent
PageTop[cacheNumObjCount]: <H1>Num Object Count @ shadow</H1>
YLegend[cacheNumObjCount]: # of objects
ShortLegend[cacheNumObjCount]: objects
LegendI[cacheNumObjCount]: Num Objects&nbsp;
LegendO[cacheNumObjCount]:
Legend1[cacheNumObjCount]: Num Objects
Legend2[cacheNumObjCount]:

Target[cacheCpuUsage]: cacheCpuUsage&cacheCpuUsage:public@shadow:3401
MaxBytes[cacheCpuUsage]: 100
AbsMax[cacheCpuUsage]: 100
Title[cacheCpuUsage]: CPU Usage @ shadow
Options[cacheCpuUsage]: absolute, gauge, noinfo, growright, nopercent
Unscaled[cacheCpuUsage]: dwmy
PageTop[cacheCpuUsage]: <H1>CPU Usage @ shadow</H1>
YLegend[cacheCpuUsage]: usage %
ShortLegend[cacheCpuUsage]:%
LegendI[cacheCpuUsage]: CPU Usage&nbsp;
LegendO[cacheCpuUsage]:
Legend1[cacheCpuUsage]: CPU Usage
Legend2[cacheCpuUsage]:

Target[cacheMemUsage]: cacheMemUsage&cacheMemUsage:public@shadow:3401 * 1024
MaxBytes[cacheMemUsage]: 2000000000
Title[cacheMemUsage]: Memory Usage
Options[cacheMemUsage]: gauge, growright, nopercent
PageTop[cacheMemUsage]: <H1>Total memory accounted for @ shadow</H1>
YLegend[cacheMemUsage]: Bytes
ShortLegend[cacheMemUsage]: Bytes
LegendI[cacheMemUsage]: Mem Usage&nbsp;
LegendO[cacheMemUsage]:
Legend1[cacheMemUsage]: Mem Usage
Legend2[cacheMemUsage]:

Target[cacheSysPageFaults]: cacheSysPageFaults&cacheSysPageFaults:public@shadow:3401
MaxBytes[cacheSysPageFaults]: 10000000
Title[cacheSysPageFaults]: Sys Page Faults @ shadow
Options[cacheSysPageFaults]: growright, nopercent
PageTop[cacheSysPageFaults]: <H1>Sys Page Faults @ shadow</H1>
YLegend[cacheSysPageFaults]: page faults/sec
ShortLegend[cacheSysPageFaults]: PF/s
LegendI[cacheSysPageFaults]: Page Faults&nbsp;
LegendO[cacheSysPageFaults]:
Legend1[cacheSysPageFaults]: Page Faults
Legend2[cacheSysPageFaults]:

Target[cacheSysVMsize]: cacheSysVMsize&cacheSysVMsize:public@shadow:3401 * 1024
MaxBytes[cacheSysVMsize]: 1000000000
Title[cacheSysVMsize]: Storage Mem Size @ shadow
Options[cacheSysVMsize]: gauge, growright, nopercent
PageTop[cacheSysVMsize]: <H1>Storage Mem Size @ shadow</H1>
YLegend[cacheSysVMsize]: mem size
ShortLegend[cacheSysVMsize]: Bytes
LegendI[cacheSysVMsize]: Mem Size&nbsp;
LegendO[cacheSysVMsize]:
Legend1[cacheSysVMsize]: Mem Size
Legend2[cacheSysVMsize]:

Target[cacheSysStorage]: cacheSysStorage&cacheSysStorage:public@shadow:3401
MaxBytes[cacheSysStorage]: 1000000000
Title[cacheSysStorage]: Storage Swap Size @ shadow
Options[cacheSysStorage]: gauge, growright, nopercent
PageTop[cacheSysStorage]: <H1>Storage Swap Size @ shadow</H1>
YLegend[cacheSysStorage]: swap size (KB)
ShortLegend[cacheSysStorage]: KBytes
LegendI[cacheSysStorage]: Swap Size&nbsp;
LegendO[cacheSysStorage]:
Legend1[cacheSysStorage]: Swap Size
Legend2[cacheSysStorage]:

Target[cacheSysNumReads]: cacheSysNumReads&cacheSysNumReads:public@shadow:3401
MaxBytes[cacheSysNumReads]: 10000000
Title[cacheSysNumReads]: HTTP I/O number of reads @ shadow
Options[cacheSysNumReads]: growright, nopercent
PageTop[cacheSysNumReads]: <H1>HTTP I/O number of reads @ shadow</H1>
YLegend[cacheSysNumReads]: reads/sec
ShortLegend[cacheSysNumReads]: reads/s
LegendI[cacheSysNumReads]: I/O&nbsp;
LegendO[cacheSysNumReads]:
Legend1[cacheSysNumReads]: I/O
Legend2[cacheSysNumReads]:

Target[cacheCpuTime]: cacheCpuTime&cacheCpuTime:public@shadow:3401
MaxBytes[cacheCpuTime]: 1000000000
Title[cacheCpuTime]: Cpu Time
Options[cacheCpuTime]: gauge, growright, nopercent
PageTop[cacheCpuTime]: <H1>Amount of cpu seconds consumed @ shadow</H1>
YLegend[cacheCpuTime]: cpu seconds
ShortLegend[cacheCpuTime]: cpu seconds
LegendI[cacheCpuTime]: Mem Time&nbsp;
LegendO[cacheCpuTime]:
Legend1[cacheCpuTime]: Mem Time
Legend2[cacheCpuTime]:

Target[cacheMaxResSize]: cacheMaxResSize&cacheMaxResSize:public@shadow:3401 * 1024
MaxBytes[cacheMaxResSize]: 1000000000
Title[cacheMaxResSize]: Max Resident Size
Options[cacheMaxResSize]: gauge, growright, nopercent
PageTop[cacheMaxResSize]: <H1>Maximum Resident Size @ shadow</H1>
YLegend[cacheMaxResSize]: Bytes
ShortLegend[cacheMaxResSize]: Bytes
LegendI[cacheMaxResSize]: Size&nbsp;
LegendO[cacheMaxResSize]:
Legend1[cacheMaxResSize]: Size
Legend2[cacheMaxResSize]:

Target[cacheCurrentLRUExpiration]: cacheCurrentLRUExpiration&cacheCurrentLRUExpiration:public@shadow:3401
MaxBytes[cacheCurrentLRUExpiration]: 1000000000
Title[cacheCurrentLRUExpiration]: LRU Expiration Age
Options[cacheCurrentLRUExpiration]: gauge, growright, nopercent
PageTop[cacheCurrentLRUExpiration]: <H1>Storage LRU Expiration Age @ shadow</H1>
YLegend[cacheCurrentLRUExpiration]: expir (days)
ShortLegend[cacheCurrentLRUExpiration]: days
LegendI[cacheCurrentLRUExpiration]: Age&nbsp;
LegendO[cacheCurrentLRUExpiration]:
Legend1[cacheCurrentLRUExpiration]: Age
Legend2[cacheCurrentLRUExpiration]:

Target[cacheCurrentUnlinkRequests]: cacheCurrentUnlinkRequests&cacheCurrentUnlinkRequests:public@shadow:3401
MaxBytes[cacheCurrentUnlinkRequests]: 1000000000
Title[cacheCurrentUnlinkRequests]: Unlinkd Requests
Options[cacheCurrentUnlinkRequests]: growright, nopercent
PageTop[cacheCurrentUnlinkRequests]: <H1>Requests given to unlinkd @ shadow</H1>
YLegend[cacheCurrentUnlinkRequests]: requests/sec
ShortLegend[cacheCurrentUnlinkRequests]: reqs/s
LegendI[cacheCurrentUnlinkRequests]: Unlinkd requests&nbsp;
LegendO[cacheCurrentUnlinkRequests]:
Legend1[cacheCurrentUnlinkRequests]: Unlinkd requests
Legend2[cacheCurrentUnlinkRequests]:

Target[cacheCurrentUnusedFileDescrCount]: cacheCurrentUnusedFileDescrCount&cacheCurrentUnusedFileDescrCount:public@shadow:3401
MaxBytes[cacheCurrentUnusedFileDescrCount]: 1000000000
Title[cacheCurrentUnusedFileDescrCount]: Available File Descriptors
Options[cacheCurrentUnusedFileDescrCount]: gauge, growright, nopercent
PageTop[cacheCurrentUnusedFileDescrCount]: <H1>Available number of file descriptors @ shadow</H1>
YLegend[cacheCurrentUnusedFileDescrCount]: # of FDs
ShortLegend[cacheCurrentUnusedFileDescrCount]: FDs
LegendI[cacheCurrentUnusedFileDescrCount]: File Descriptors&nbsp;
LegendO[cacheCurrentUnusedFileDescrCount]:
Legend1[cacheCurrentUnusedFileDescrCount]: File Descriptors
Legend2[cacheCurrentUnusedFileDescrCount]:

Target[cacheCurrentReservedFileDescrCount]: cacheCurrentReservedFileDescrCount&cacheCurrentReservedFileDescrCount:public@shadow:3401
MaxBytes[cacheCurrentReservedFileDescrCount]: 1000000000
Title[cacheCurrentReservedFileDescrCount]: Reserved File Descriptors
Options[cacheCurrentReservedFileDescrCount]: gauge, growright, nopercent
PageTop[cacheCurrentReservedFileDescrCount]: <H1>Reserved number of file descriptors @ shadow</H1>
YLegend[cacheCurrentReservedFileDescrCount]: # of FDs
ShortLegend[cacheCurrentReservedFileDescrCount]: FDs
LegendI[cacheCurrentReservedFileDescrCount]: File Descriptors&nbsp;
LegendO[cacheCurrentReservedFileDescrCount]:
Legend1[cacheCurrentReservedFileDescrCount]: File Descriptors
Legend2[cacheCurrentReservedFileDescrCount]:

Target[cacheClients]: cacheClients&cacheClients:public@shadow:3401
MaxBytes[cacheClients]: 1000000000
Title[cacheClients]: Number of Clients
Options[cacheClients]: gauge, growright, nopercent
PageTop[cacheClients]: <H1>Number of clients accessing cache @ shadow</H1>
YLegend[cacheClients]: clients/sec
ShortLegend[cacheClients]: clients/s
LegendI[cacheClients]: Num Clients&nbsp;
LegendO[cacheClients]:
Legend1[cacheClients]: Num Clients
Legend2[cacheClients]:

Target[cacheHttpAllSvcTime]: cacheHttpAllSvcTime.5&cacheHttpAllSvcTime.60:public@shadow:3401
MaxBytes[cacheHttpAllSvcTime]: 1000000000
Title[cacheHttpAllSvcTime]: HTTP All Service Time
Options[cacheHttpAllSvcTime]: gauge, growright, nopercent
PageTop[cacheHttpAllSvcTime]: <H1>HTTP all service time @ shadow</H1>
YLegend[cacheHttpAllSvcTime]: svc time (ms)
ShortLegend[cacheHttpAllSvcTime]: ms
LegendI[cacheHttpAllSvcTime]: Median Svc Time (5min)&nbsp;
LegendO[cacheHttpAllSvcTime]: Median Svc Time (60min)&nbsp;
Legend1[cacheHttpAllSvcTime]: Median Svc Time
Legend2[cacheHttpAllSvcTime]: Median Svc Time

Target[cacheHttpMissSvcTime]: cacheHttpMissSvcTime.5&cacheHttpMissSvcTime.60:public@shadow:3401
MaxBytes[cacheHttpMissSvcTime]: 1000000000
Title[cacheHttpMissSvcTime]: HTTP Miss Service Time
Options[cacheHttpMissSvcTime]: gauge, growright, nopercent
PageTop[cacheHttpMissSvcTime]: <H1>HTTP miss service time @ shadow</H1>
YLegend[cacheHttpMissSvcTime]: svc time (ms)
ShortLegend[cacheHttpMissSvcTime]: ms
LegendI[cacheHttpMissSvcTime]: Median Svc Time (5min)&nbsp;
LegendO[cacheHttpMissSvcTime]: Median Svc Time (60min)&nbsp;
Legend1[cacheHttpMissSvcTime]: Median Svc Time
Legend2[cacheHttpMissSvcTime]: Median Svc Time

Target[cacheHttpNmSvcTime]: cacheHttpNmSvcTime.5&cacheHttpNmSvcTime.60:public@shadow:3401
MaxBytes[cacheHttpNmSvcTime]: 1000000000
Title[cacheHttpNmSvcTime]: HTTP Near Miss Service Time
Options[cacheHttpNmSvcTime]: gauge, growright, nopercent
PageTop[cacheHttpNmSvcTime]: <H1>HTTP near miss service time @ shadow</H1>
YLegend[cacheHttpNmSvcTime]: svc time (ms)
ShortLegend[cacheHttpNmSvcTime]: ms
LegendI[cacheHttpNmSvcTime]: Median Svc Time (5min)&nbsp;
LegendO[cacheHttpNmSvcTime]: Median Svc Time (60min)&nbsp;
Legend1[cacheHttpNmSvcTime]: Median Svc Time
Legend2[cacheHttpNmSvcTime]: Median Svc Time

Target[cacheHttpHitSvcTime]: cacheHttpHitSvcTime.5&cacheHttpHitSvcTime.60:public@shadow:3401
MaxBytes[cacheHttpHitSvcTime]: 1000000000
Title[cacheHttpHitSvcTime]: HTTP Hit Service Time
Options[cacheHttpHitSvcTime]: gauge, growright, nopercent
PageTop[cacheHttpHitSvcTime]: <H1>HTTP hit service time @ shadow</H1>
YLegend[cacheHttpHitSvcTime]: svc time (ms)
ShortLegend[cacheHttpHitSvcTime]: ms
LegendI[cacheHttpHitSvcTime]: Median Svc Time (5min)&nbsp;
LegendO[cacheHttpHitSvcTime]: Median Svc Time (60min)&nbsp;
Legend1[cacheHttpHitSvcTime]: Median Svc Time
Legend2[cacheHttpHitSvcTime]: Median Svc Time

Target[cacheIcpQuerySvcTime]: cacheIcpQuerySvcTime.5&cacheIcpQuerySvcTime.60:public@shadow:3401
MaxBytes[cacheIcpQuerySvcTime]: 1000000000
Title[cacheIcpQuerySvcTime]: ICP Query Service Time
Options[cacheIcpQuerySvcTime]: gauge, growright, nopercent
PageTop[cacheIcpQuerySvcTime]: <H1>ICP query service time @ shadow</H1>
YLegend[cacheIcpQuerySvcTime]: svc time (ms)
ShortLegend[cacheIcpQuerySvcTime]: ms
LegendI[cacheIcpQuerySvcTime]: Median Svc Time (5min)&nbsp;
LegendO[cacheIcpQuerySvcTime]: Median Svc Time (60min)&nbsp;
Legend1[cacheIcpQuerySvcTime]: Median Svc Time
Legend2[cacheIcpQuerySvcTime]: Median Svc Time

Target[cacheIcpReplySvcTime]: cacheIcpReplySvcTime.5&cacheIcpReplySvcTime.60:public@shadow:3401
MaxBytes[cacheIcpReplySvcTime]: 1000000000
Title[cacheIcpReplySvcTime]: ICP Reply Service Time
Options[cacheIcpReplySvcTime]: gauge, growright, nopercent
PageTop[cacheIcpReplySvcTime]: <H1>ICP reply service time @ shadow</H1>
YLegend[cacheIcpReplySvcTime]: svc time (ms)
ShortLegend[cacheIcpReplySvcTime]: ms
LegendI[cacheIcpReplySvcTime]: Median Svc Time (5min)&nbsp;
LegendO[cacheIcpReplySvcTime]: Median Svc Time (60min)&nbsp;
Legend1[cacheIcpReplySvcTime]: Median Svc Time
Legend2[cacheIcpReplySvcTime]: Median Svc Time

Target[cacheDnsSvcTime]: cacheDnsSvcTime.5&cacheDnsSvcTime.60:public@shadow:3401
MaxBytes[cacheDnsSvcTime]: 1000000000
Title[cacheDnsSvcTime]: DNS Service Time
Options[cacheDnsSvcTime]: gauge, growright, nopercent
PageTop[cacheDnsSvcTime]: <H1>DNS service time @ shadow</H1>
YLegend[cacheDnsSvcTime]: svc time (ms)
ShortLegend[cacheDnsSvcTime]: ms
LegendI[cacheDnsSvcTime]: Median Svc Time (5min)&nbsp;
LegendO[cacheDnsSvcTime]: Median Svc Time (60min)&nbsp;
Legend1[cacheDnsSvcTime]: Median Svc Time
Legend2[cacheDnsSvcTime]: Median Svc Time

Target[cacheRequestHitRatio]: cacheRequestHitRatio.5&cacheRequestHitRatio.60:public@shadow:3401
MaxBytes[cacheRequestHitRatio]: 100
AbsMax[cacheRequestHitRatio]: 100
Title[cacheRequestHitRatio]: Request Hit Ratio @ shadow
Options[cacheRequestHitRatio]: absolute, gauge, noinfo, growright, nopercent
Unscaled[cacheRequestHitRatio]: dwmy
PageTop[cacheRequestHitRatio]: <H1>Request Hit Ratio @ shadow</H1>
YLegend[cacheRequestHitRatio]: %
ShortLegend[cacheRequestHitRatio]: %
LegendI[cacheRequestHitRatio]: Median Hit Ratio (5min)&nbsp;
LegendO[cacheRequestHitRatio]: Median Hit Ratio (60min)&nbsp;
Legend1[cacheRequestHitRatio]: Median Hit Ratio
Legend2[cacheRequestHitRatio]: Median Hit Ratio

Target[cacheRequestByteRatio]: cacheRequestByteRatio.5&cacheRequestByteRatio.60:public@shadow:3401
MaxBytes[cacheRequestByteRatio]: 100
AbsMax[cacheRequestByteRatio]: 100
Title[cacheRequestByteRatio]: Byte Hit Ratio @ shadow
Options[cacheRequestByteRatio]: absolute, gauge, noinfo, growright, nopercent
Unscaled[cacheRequestByteRatio]: dwmy
PageTop[cacheRequestByteRatio]: <H1>Byte Hit Ratio @ shadow</H1>
YLegend[cacheRequestByteRatio]: %
ShortLegend[cacheRequestByteRatio]:%
LegendI[cacheRequestByteRatio]: Median Hit Ratio (5min)&nbsp;
LegendO[cacheRequestByteRatio]: Median Hit Ratio (60min)&nbsp;
Legend1[cacheRequestByteRatio]: Median Hit Ratio
Legend2[cacheRequestByteRatio]: Median Hit Ratio

Target[cacheBlockingGetHostByAddr]: cacheBlockingGetHostByAddr&cacheBlockingGetHostByAddr:public@shadow:3401
MaxBytes[cacheBlockingGetHostByAddr]: 1000000000
Title[cacheBlockingGetHostByAddr]: Blocking gethostbyaddr
Options[cacheBlockingGetHostByAddr]: growright, nopercent
PageTop[cacheBlockingGetHostByAddr]: <H1>Blocking gethostbyaddr count @ shadow</H1>
YLegend[cacheBlockingGetHostByAddr]: blocks/sec
ShortLegend[cacheBlockingGetHostByAddr]: blocks/s
LegendI[cacheBlockingGetHostByAddr]: Blocking&nbsp;
LegendO[cacheBlockingGetHostByAddr]:
Legend1[cacheBlockingGetHostByAddr]: Blocking
Legend2[cacheBlockingGetHostByAddr]:


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] Senate should demand electric grid reliability and security

http://thehill.com/blogs/congress-blog/energy-environment/211238-senate-should-demand-electric-grid-reliability-and By Thomas S. Popik and William R. Graham The Hill July 07, 2014 With a Senate vote on two nominees for commissioners of the Federal Energy Regulatory Commission (FERC) pending, there is unprecedented attention on this obscure regulator of interstate pipelines and electricity transmission. In 2005, Congress granted FERC additional authority to regulate electric grid reliability and security, but too often FERC has accommodated industry rather than enforce strict standards. Both FERC nominees, Cheryl LaFleur and Norman Bay, have long tenures as commissioner and director of Enforcement, respectively. Before a confirmation vote, Senators should examine FERC’s weak regulatory record and determine whether leadership and legislative fixes are necessary. Prior to the 2003 Northeast Blackout which affected 50 million people, electric grid reliability and security were unregulated. An industry trade association had set voluntary standards but compliance was spotty. After the Northeast Blackout, a special U.S.-Canada task force identified the voluntary standards system as a prime cause. In response, Congress designed a hybrid regulatory system, where a private successor to the trade association, the North American Electric Reliability Corporation (NERC), would set mandatory standards. FERC would have authority to request, review, and approve, but not change, NERC’s standards. Nominee and Acting FERC Chair LaFleur, formerly a senior utility executive, is a supporter of the hybrid FERC-NERC regulatory system. At an April Senate hearing entitled, “Keeping the lights on


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] The $10 Million Deductible – Why the cyberinsurance industry is a mess.

http://www.slate.com/articles/technology/future_tense/2014/06/target_breach_cyberinsurance_is_a_mess.html By Josephine Wolff Slate.com June 12, 2014 Do you still shop at Target? There’s been controversy over how much of an impact the massive breach of 40 million credit and debit card numbers in late 2013 had on the company’s shareholders and customers. And that controversy speaks to a larger cybersecurity problem plaguing industry today: the difficulty of assessing the impact and costs of these sorts of security breaches and the challenges that presents when it comes to trying to buy and sell cyberinsurance. Yes, that’s a real thing—and a great business to be in, at the moment, if you can figure out how to develop accurate actuarial models, that is. A recent New York Times article touted cyberinsurance as the “fastest-growing niche in the [insurance] industry today.” Nicole Perlroth and Elizabeth Harris report: “[A]fter the breach at Target, its profit was cut nearly in half—down 46 percent over the same period the year before—in large part because the breach scared away its customers.” These enormous costs to brand reputation make it difficult for companies to get as much cyber risk coverage as they want, and the demand is only growing. The Times cites statistics showing a 21 percent increase in demand for cyberinsurance policies from 2012 to 2013, with total premiums reaching $1.3 billion last year and individual companies able to acquire a maximum of roughly $300 million in coverage. At the time of its breach, Target had only $100 million in coverage, with a $10 million deductible, and had been turned away by at least one insurer when it tried to acquire more cyberinsurance, Perlroth and Harris report. They suggest that this coverage may fall well short of the massive losses incurred by the company when it saw its profits nearly halved. But their piece comes less than a month after Eric Chemi argued exactly the opposite about the impact of Target’s security breach in a piece for Bloomberg Businessweek titled “Investors Couldn’t Care Less About Data Breaches.” He wrote: […]


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] How IT security experts handle healthcare network access

http://healthitsecurity.com/2014/05/27/how-it-security-experts-handle-healthcare-network-access/ By Patrick Ouellette Health IT Security May 27, 2014 Healthcare network security has become more complicated over the years because of the explosion of mobile device connectivity. And because it’s so difficult for healthcare organizations to have a firm grasp on where their perimeters begin and end, they must look for new ways to ensure networks are secure both internally and externally. Panelists who took part in a talk titled “Data Security in the Cloud: Leveraging the Low-Cost Advantages while Managing Risk” at the recent iHT2 conference in Boston discussed how they perceive healthcare network security and access controls. John Meyers, PhD, Assistant Professor of Medicine and Director of Technology, Department of Medicine, Boston University Medical Center, sparked the talk by explaining how there’s occasionally there’s going to be some protected health (PHI) out there that shouldn’t be. But if an organization limits the number of users who have access to the data, it can help mitigate those risks. David Reis, PhD, CISO, VP of IT Governance, PMO and Security at Lahey Health explained how Lahey essentially stopped trusting its inside network two years ago in the same way it doesn’t trust everyone externally. When asked what this change in trust measures meant, Reis said there were a few different considerations involved, starting with no longer trusting internal users. […]


Facebooktwittergoogle_plusredditpinterestlinkedinmail