He’s a bit indignant that so much energy goes to sporting events like the Olympics rather than more important news that isn’t getting reported around the world.

This is in a year when tons of journalists are getting laid off.

This is in a year when there are tons of stories around the world that aren’t getting reported on.

Could we take half of those photographers and send them to Russia, for instance

Reminds me of a feeling I had back in college as an undergrad student studying social sciences and humanities, about the way my friends who were physicists interacted with the world. They were so awed by the stars, Mars, astrophysics, and it seemed to me interesting but altogether unimportant. They argued they may find something outside our planet that could help solve Earth-bound problems like disease, or find the origins of earth and humanity — but really they were doing it because they loved it. One of my friends had a good argument, though — there are enough people right now that we can specialize in what we care about, and there will still be others covering other topics. He could be a physicist and look into the universe’s origin, while I studied social interaction and writing, and our other friends looked into solving cancer or eradicating invasive plants in the native wetlands. We have to specialize, and there are enough of us to do it too.

I think it’s the same way in journalism — whether it’s sports, celebrity journalism, or coverage of politics and war, there are a lot of opportunities right now for journalists. Of course the business model is changing, and some old-schoolers won’t know how to roll with that, but generations change slowly; we’re learning.

Also, the Olympics is seen as more than a sporting event, it’s also a symbol of world competition and cooperation too — a way for countries to come together and share entertainment globally. I think that’s worth covering.

In the second post, Robert Scoble says there are plenty of great journalists but the public doesn’t care. In some ways I have to agree with that, but I don’t think it’s negative, necessarily. I had a conversation with someone the other day about world news reportage. He says, “I was just reading this story, but what does it matter to me if there’s a flood in some city in another country I’ll never visit and some farmer lost his sheep?” World news is only important when it’s relevant, so it’s no wonder that many people don’t care — if they don’t know much about the area, and it doesn’t affect them, they have no incentive to give it full attention. You can call that apathy, but I think it’s an important selectivity skill that humans have. We have to choose what to give priority to, so if nothing stands out as being particularly important, we just ignore it or gloss over it. Human nature…

Also I think the common person today just gets desensitized and doesn’t know where to turn their energy, when surrounded by so many crises. Either you focus on one specialty and do your best to work toward one cause in your life — and maybe that’s just in the course of your daily work — or you become a complete Attention-Deficit-Disorder case and bounce from one problem to the next, without knowing how to solve anything. That just causes a sense of bewilderment, despair, and either that bogs you down or eventually you get desensitized.

There’s a commenter on Scoble’s blog, Spencer, who talks about this generation’s apathy. There are so many people who want to blame today’s generation or the young generation for this “apathy” that they sense. But I see it as a survival mechanism that arises from the way information flows these days. We’re surrounded by crises, everyone wants us to know about them — the water shortage, global warming, death in Iraq, the national deficit. Okay, crisis, I get it. But no one gives a real clear idea on what any individual is really supposed to do to solve the problem. You can’t get involved with one global cause, without ignoring all the others, and if you do get involved it’s likely to become your life’s purpose. Most people are concerned with other things — their families, their work, personal development, their homes and futures, and really that’s enough to take up all their time.

I’m always amazed when I read about the early unionists. Emma Goldman for example, the activist who pushed for the 8-hr workday, and campaigned for free love in the early 1900s when women were still wearing corsets, used to work 16 hour factory days as a seamstress, then lead meetings late into the night. Today we lead cushy lives comparatively–8 hour days, plus commute and lunch, family time, dinner time, gym maybe, sleep… but it still doesn’t seem like we ever have enough energy and time.

What Emma had that most people today don’t, is a community living in the same conditions as herself, with clear goals about what they were campaigning for, and a cause that affected their own daily lives. Today, unionism and local activism is in much shorter supply, in part due to the many people who work fairly comfy desk jobs, and the problem that everyone has his own specialization, works in a cubicle, does his or her own thing. The problems we’re facing today in terms of global warming, global water shortage, aren’t the same kinds of problems that activists have fought for in the past, and there’s no clear road map for how to solve them. Our leaders sure aren’t leading the way.

What we do have, at least, is the Olympics, which is an age old symbol of international cooperation, play and competition…so, uh, go sports! As for full disclosure, I don’t actually have a TV and haven’t watched the Olympics in many years, but I do try taking short showers–does that help?

“You’re hired on at a new company placed in charge of securing their online business (websites). You know next to nothing about the technical details of the infrastructure other than they have no existing web/software security program and a significant portion of the organizations revenues are generated through their websites.

What is the very first thing do on day 1?”

At about the same time, I saw a message posted to one of the mailing lists where the poster wondered: "I’ve been asked to look into finding a replacement to our current log management/auditing system.  This is a field I haven’t even come close to touching before, and really don’t know the ideal things to look for (or ignore), etc. I’ve been searching through SANS site as well as googling, and I’m not coming up with a lot of great starter information. " And then he asks "Where should I start?"

This is indeed a really good question!  Let's rephrase the above for the case of logging:

"You’re hired on at a new company placed in charge of TAKING CONTROL OVER THE LOGS. You know next to nothing about the technical details of the infrastructure other than they have no existing LOG MANAGEMENT process and tools... What is the very first thing do on day 1?”

So the "Day 1" of log management project. What's up?!

The very first thought that should cross you mind before you even do whatever first thing you wanted to do is "WHY?" (don't people hate those 'Why?" questions - focusing on "What?" or "How?" is soooooooo much easier....)

"Log management" is a solution, not a problem. What is your problem that you now have a mandate to solve?

Logs don't just drop on people :-) Well, not often.

What is it that motivated your boss (or his boss, or whoever) to decide to "address this", to "take control over logs?" Was it a new compliance mandate, PCI perhaps? Was it a recent incident where investigation hit the wall due to utter lack of logs? Was it a new corporation-wide IT efficiency improvement project? Was it a lawsuit where an e-discovery request was not satisfied and thus fine was levied? Was it a hot IT project that is impossible to complete without having a tool to analyze logs?

This "need" is very important since logging is a huge realm and not focusing on the need is akin to starting a journey into a hostile wilderness without  a map - in other words, it might be fun for a while, but it can end badly :-)

Next, what do you actually do first? Figure out what logs are needed for this effort and what systems produce them (and who "owns" them!) Analyzing SAP logs for J-SOX is a VERY different effort from analyzing Cisco ASA logs for network troubleshooting.

Only at this point you can start thinking about "tools:" parsers, logs, databases, reports, alerts, indexing and other technical thingies as well as capacity planning, scalability, etc. This is the stage where you learn the lingo and learn to cut through marketing messaging to get to the actual tool capabilities.

So, remember: given mandate to "tame the logging monster", think "WHY?" first!

Because of non-disclosure and other confidentiality contracts with various partners, vendors and manufacturers, we’ve had sealed lips for almost exactly 12 months. Now that it’s been made public by the media, I can share a little information with you and explain why I think you should be excited.

What cat is out of the bag now? HP ProCurve’s network access control solution leverages endpoint management technology from StillSecure’s Secure Access solution. Information Week spilled the beans, so to speak, in Mike Fratto’s recent 2008 NAC Survey Analytic Report. (See page 32)

Now, at this point, I can probably lump you into one of three groups… 1) You don’t care or have no clue what this means 2) You care but think this means HP ‘has no NAC’… or group 3) You know about StillSecure’s success and ProCurve’s integration and think this is a great combination.

I’m sure everyone will have their own opinion- I happen to be in Group 3. Why? Because HP has taken the power of their servers, leveraged a very solid endpoint management tool and incorporated a variety of other management and security features by way of their identity management solution.

• The endpoint security. StillSecure’s Safe Access solution has been winning awards and earning stars for years. You can probably Google it, or check out some of Shimel’s blog  posts, such as this one, with 4- and 5-star reviews from SC Magazine. In fact, just this year (and in previous years) Safe Access was voted Best Endpoint Security Solution by SC Magazine and has won numerous other awards and accolades from various analysts and media firms. They have a clean, user-friendly GUI, a solid Linux platform and a variety of testing methods, deployment options and switch integrations. (And no, you don’t need ProCurve switches, the NAC integration is ready for your Cisco, Extreme, or whatever you have).

• User management. Combine one of the highest-rated endpoint security solutions with ProCurve switches, the #2 leader in the switching market (and Magic Quadrant resident) and the full integration with ProCurve’s Identity Driven Manager platform and you have one amazingly capable access control system. With ProCurve IDM, you can integrate directly with their NAC 800 appliance to offer per-user (or per-group) ACLs, QoS, restrictions or priviliges. Rules can be identity-based, time-based, location-based, or a combination of all. And, IDM eases 802.1X integration by offering users a central management and repository for user settings and VLAN assignments; it really is ProCurve’s special sauce and a distinguishing feature.

• Switch security. The integration of advanced switch security functions, such as DHCP snooping, Dynamic ARP protection and dynamic IP lockdown gives ProCurve another leg-up to fight common known attacks for both in-line and out-of-band NAC deployments.

• Zero-day protection. It gets better, the new Dynamic Configuration Arbiter (DCA) functions in ProCurve’s Pro-vision switches gives customers the unique advantage of integrating the NAC and IDM with ProCurve’s Network Immunity Solution (NIM). NIM uses flow analysis from sFlow and network behaviour anomaly detection (NBAD) to detect and automatically remediate on the edge. In English, that means we can use ProCurve’s NIM to detect attacks and take action at the edge port, such as blocking the port, locking out the MAC address of the offender, rate-limiting, or even mirroring the traffic to an IDS for further inspection. The super-nice part is, all the sFlow and NBAD works on wireless too. (Hey Stiennon, did you hear that?)

• Full integration. Unlike some of the other network-based NAC vendors, ProCurve has done an exceptional job of integrating these features and we’ll continue to see more integration in future revisions of the softwares and as more TNC/TCG integration frameworks are released (such as IF-MAP).

I think the strong integration with the infrastructure and the ability to leverage a mature endpoint integrity will make HP a ‘real’ player in the NAC market moving forward.

Not to knock other NAC solutions- Choosing a NAC is like selecting the perfect wine for your dish- there’s no 1 ‘right’ choice for all occasions. Each have their advantages and disadvantages. There are several that have special sauces and you’ll actually be seeing more on that soon…

# # #

Contact me if you think you can attend.

Blogger: Ramon Krikken

Many different conference tracks, many different perspectives on 'security' and how to best implement it. I spent most of my time in the Service-Oriented Architecture (SOA) track, looking for little nuggets of wisdom to help with my upcoming SOA security overview, and I certainly did find some. There were - luckily - no huge upsets, but there were certainly lots of questions on how to to implement controls in a service-oriented environment. What was once only the question of what Web Services standards to use, has now evolved to discussions on everything from high-level architecture to the minutiae of security token translations.

One of the discussions in SOA security revolves around the location of controls. In general the architecture is best served if most controls, such as authentication and authorization, are externalized from the application code. It creates a separation of concerns, and usually makes management and auditing more straightforward. So some of the different infrastructure components, like web services modules and the XML gateways, support access control, encryption, and data validation features. Some vendors would like us to believe that pushing all this functionality into their well-packaged, standards-based solution is going to solve the 'security problem,' but does it?

It all works out well as long as we can - in the true spirit of service orientation - view the service as a black box, but that isn't necessarily possible from a security perspective. Certain functionality, like the compute-intensive XML schema validation, is an ideal candidate for infrastructure security, and so is service-to-service authentication. User authorization is all over the map depending on its granularity and requirements for data-awareness. With encryption it also depends on whether we're talking data transport or storage. Service-enabling legacy applications also throws us a curve-ball because of, amongst things, the need for identity and access token mapping that take us into the darkness of the black-box service.

In other words, both applying controls in service orientation, and applying service-oriented principles to security, aren't necessarily as straightforward as some may want us to believe. Security professionals probably already had a feeling this would be the case; we're a bunch of skeptics, after all. But if it's the case that enterprise architecture is far ahead of security architecture in SOA planning or implementation, then there may be some misunderstanding in the organization on how to secure the infrastructure and services. At the surface, and in the common case, the decision to put controls at the infrastructure level seems simple. The devil, it appears, is very much in the details that are invisible to us in some of the higher-level architectural discussions.

Fortunately, all is not lost. We may have thought that 'the SOA train has left the station, and security is not on board,' but it now appears - at least from Burton Group's research - that the train isn't necessarily all too far down the tracks yet. We need to work with the architects to create a security strategy that matures along with the other aspects of SOA implementation, work with the development team to overcome the challenges of building security into the SDLC, and most of all, work with ourselves to make sure we're able to apply consistent principles of information assurance no matter what the next best thing in SOA technology is. There is time to get things right, and the best time to start is now. 

Blogger: Ramon Krikken

Many different conference tracks, many different perspectives on 'security' and how to best implement it. I spent most of my time in the Service-Oriented Architecture (SOA) track, looking for little nuggets of wisdom to help with my upcoming SOA security overview, and I certainly did find some. There were - luckily - no huge upsets, but there were certainly lots of questions on how to to implement controls in a service-oriented environment. What was once only the question of what Web Services standards to use, has now evolved to discussions on everything from high-level architecture to the minutiae of security token translations.

One of the discussions in SOA security revolves around the location of controls. In general the architecture is best served if most controls, such as authentication and authorization, are externalized from the application code. It creates a separation of concerns, and usually makes management and auditing more straightforward. So some of the different infrastructure components, like web services modules and the XML gateways, support access control, encryption, and data validation features. Some vendors would like us to believe that pushing all this functionality into their well-packaged, standards-based solution is going to solve the 'security problem,' but does it?

It all works out well as long as we can - in the true spirit of service orientation - view the service as a black box, but that isn't necessarily possible from a security perspective. Certain functionality, like the compute-intensive XML schema validation, is an ideal candidate for infrastructure security, and so is service-to-service authentication. User authorization is all over the map depending on its granularity and requirements for data-awareness. With encryption it also depends on whether we're talking data transport or storage. Service-enabling legacy applications also throws us a curve-ball because of, amongst things, the need for identity and access token mapping that take us into the darkness of the black-box service.

In other words, both applying controls in service orientation, and applying service-oriented principles to security, aren't necessarily as straightforward as some may want us to believe. Security professionals probably already had a feeling this would be the case; we're a bunch of skeptics, after all. But if it's the case that enterprise architecture is far ahead of security architecture in SOA planning or implementation, then there may be some misunderstanding in the organization on how to secure the infrastructure and services. At the surface, and in the common case, the decision to put controls at the infrastructure level seems simple. The devil, it appears, is very much in the details that are invisible to us in some of the higher-level architectural discussions.

Fortunately, all is not lost. We may have thought that 'the SOA train has left the station, and security is not on board,' but it now appears - at least from Burton Group's research - that the train isn't necessarily all too far down the tracks yet. We need to work with the architects to create a security strategy that matures along with the other aspects of SOA implementation, work with the development team to overcome the challenges of building security into the SDLC, and most of all, work with ourselves to make sure we're able to apply consistent principles of information assurance no matter what the next best thing in SOA technology is. There is time to get things right, and the best time to start is now. 

Ted Morgan, the head of Skyhook, explained in an interview that while GPS is certainly the gold standard, and while it works well in stand-alone devices designed for continuous use and navigation, it's not the right choice by itself for mobile devices. It can take 5 or 10 minutes for a GPS-only device to get an accurate fix on the satellites it needs to give you accurate information. (Various shortcuts can provide less accurate information more quickly.)

"This notion of 'tell a user or consumer to stand outside for 30 seconds before they can search for the nearest pharmacy' is pretty silly," Morgan said. He noted that with all the radios now found in newer mobile devices, using several of them produces a fast and much more accurate result. The iPhone 3G, for instance, sports quad-band 2G, tri-band 3G, Bluetooth, Wi-Fi, and GPS chips.

Morgan said that A-GPS (assisted GPS) already combines cell tower information with GPS. A cell phone can be told approximately where it is, and thus instead of cycling through 24 satellites, start with the two that are most directly overhead. This can reduce the time to gain a location to as little as 20 seconds, Morgan said, although any kind of movement usually lengthens the time to 30 to 60 seconds.

Skyhook's system takes advantage of this aspect of A-GPS. They let a GPS system grab onto two satellites quickly to correct data from their Wi-Fi Position System (WPS). Morgan said that this reduces the WPS error by 35 to 40 percent through "weak fixes."

Within cities' concrete canyons, "you can only get a true GPS fix about 70 percent of the time outdoor, but you get two satellites all the time," Morgan said. "In the entire footprint, we're able to use this hybrid technology, even though GPS is only available 70 percent of the time." Outside of metro areas, cell towers can still be used to improve GPS startup times.

Skyhook has continued to expand its European coverage for WPS; they cover about 8,000 cities in the US and Canada, which is roughly 70 percent of the population; "it looks exactly like a cellular coverage map," Morgan said, and includes "any town with five streets in it."

In Europe, their current big push, partly because of their inclusion in the iPhone, they cover 70 percent of population in the current countries--the UK, France, and Germany--but they're now at 50 percent of the population of the rest of Western Europe. They're working assiduously in Japan, Korea, Hong Kong, and Australia as well, and looking into China and India. India has very little Wi-Fi, so they may rely more on cell towers there.

The company also announced a partnership with wireless chip maker CSR today, which is a major providers of Wi-Fi and Bluetooth chips to computer and handset makers. Nearly a year and a half ago, Skyhook partnered with SiRF, the dominant worldwide chip supplier for stand-alone GPS gear, that's also making a push into mobile devices. Skyhook obviously needs a win with a cell chip maker, like Infineon, Broadcom, or Qualcomm, given the XPS technology, to score a place in tens of millions of cell phones beyond the iPhone.

Skyhook's technology most recently appeared in a soon-to-ship model of the Eye-Fi--the Explore. The $130 Secure Digital card with Wi-Fi built in allows you to take pictures with any camera, and have the Wi-Fi signal space recorded for later lookup when you upload photos. The pictures are geotagged with that information. The card can optionally be used with Wayport's 10,000 strong Wi-Fi network in the U.S for $15 extra per month. David Pogue of The New York Times recently wrote up the Eye-Fi Explore.

Your first real lesson about locking down a host was how to reduce its attack surface. You learned how to disable services using /etc/inetd.conf. Then you learned about rc.d and how to prevent unnecessary services from being launched at startup. Next, maybe you configured the Xserver to disallow remote connections or moved on to removing setuid permissions from files. As you worked, you’d periodically re-scan the box to gauge progress, asking yourself “have I removed everything I don’t need?” The underlying motivation, of course, is that an attacker can’t hack something that isn’t there.

You learned how to extend those concepts to the network — configuring firewall rules, router ACLs, VLANs, etc. Segmenting the network. Creating a DMZ. No need to dwell on this, you get the idea.

Eventually, people realized that applications had an attack surface too. Web servers and application servers got a lot of attention, followed closely by custom web applications. “What do you mean you can execute SQL queries against my database? That’s impossible, I have a firewall!”

Some companies, the ones who could afford it anyway, started to build security into their development cycle. Doing threat modeling during the design phase made sense, because hey, it’s much cheaper to fix security holes in a whiteboard drawing than it is to rewrite your authorization module from scratch after it’s in production.

Let’s talk strictly about custom web applications now. What I’ve observed is that most development groups, even the ones who actively engage in threat modeling, do not understand their web application’s attack surface. The lead architect can whiteboard a high-level diagram of all the major components and how they interact. Individual developers can go a bit deeper, telling you which files they touch, what database permissions they need, or how various pieces of data are encrypted in storage. At the end of this exercise you have a complete picture of the processes, data flows, protocols, privilege boundaries, external entities, and so on, and you’re well on your way to understanding all of the potential attack vectors.

Or are you?

What often gets overlooked or glossed over is the impact of external libraries or packages. Nobody writes everything from scratch. A typical list of third-party libraries for a Java-based Web 2.0 application might include DWR, GWT, Axis, and Dojo, plus about 30 other libraries to do everything from logging to parsing to image manipulation. Nine out of ten times, the libraries will be installed in full, using the default configuration from page one of the README file.

Why is this relevant? Because just as those old Unix boxes exposed unnecessary services, libraries expose unnecessary code. Let’s say you installed Dojo to simplify the process of creating an HTML table with rows and columns that can be sorted on demand. Did you remember to remove all the .js files you didn’t need? Or maybe you installed Axis or DWR or anything else that has its own Servlet(s) for processing requests. Have you compared what that Servlet can do against what you need it to do?

A fictitious example may help illustrate further. Imagine you just downloaded a new library called WhizBang. You follow the installation instructions to define and map two servlets in your web.xml file, WhizServlet and BangServlet, and you configure it to integrate with your web app. After a bit of trial and error, it’s functional. Yay! This is where most developers stop.

Nobody asks, “how much of this do I actually need?” Case in point, what if your application only uses WhizServlet? BangServlet is still exposed, and you don’t even use it! Similarly, what if WhizServlet takes an “action” parameter which can be either “view”, “edit”, or “delete”, and your application only uses “view”? You’re still exposing the other actions to anybody who knows the URL syntax (pretty trivial if it’s open source). You wouldn’t expose large chunks of your own code that you weren’t using, so why should it be any different with libraries?

This post is getting kind of long so I’m going to split it up. In the next post, I’ll continue the discussion of attack surface minimization, as well as some of the tradeoffs that go along with this approach.

At each of these opportunities, I like to ask ‘Why are you considering NAC?”

Here’s my Top 5 of Why Customers Consider NAC (or think they want NAC). This is not based on any other organization’s research or polls, nor is it based on analyst analysis. It’s not based on forethought or musings of an ‘expert’. It’s just my personal experience from my daily interactions.

#1: Endpoint Compliance
I put this one first, because I think it’s the most-hyped and possibly least significant. I know, that’s harsh, especially when endpoint compliance seems to be the big bat NAC carries around. Truth be told, it’s more of an ‘icing on the cake’ for the people I talk to. Until the auto-remediation features are a little more mature, the idea of checking for much beyond presence of anti-virus and possibly patches is unattractive. Frankly, endpoint compliance for LAN-based devices can be a Charlie Foxtrot except under the most ideal circumstances. There are many large organizations and DoD groups that need endpoint compliance, and that’s a primary driver for them. For the rest, one of the other reasons below is a primary compelling feature and endpoint checking is just another knob they can play with.

The lack of fervent interest in endpoint checking is why I had to disagree so strongly with Stiennon’s when he advises in his NWW article “Don’t even bother investing in NAC”. The entire premise of his issues with NAC center around various endpoing checking. (You can check out Shimel’s response  too Stiennon’s blog here.)

#2: Guest Access
Believe it or not, the most frequent response I get for “why are you considering NAC” is “guest access”. Guest access seems to be a thorn in every organization’s side. It’s a simple problem with impossibly complex solutions… or so they think. For years, we’ve been provisioning safe and secure guest access for customers with the use of clean and simple protocol-less VLANs and so, I know that about 82% of the time, there are much simpler ways to offer guest access than by rolling out a full NAC implementation. If guest access is your primary and only goal with a NAC solution, there’s probably a better, faster and less expensive solution. If money and time are no object, then NAC can be a good way to get from point A to B and give you a few fun technical trinkets to play with.

#3: Edge Port Security
After guest access, the next thing I hear most is interest in adding edge port security with a 802.1X NAC solution. (We call this Layer 2 NAC.) I tend to think for the time being, this is NAC’s sweet spot. Note I said ‘for the time being’, I think this may change in the next 18-24 months. But for now, the ability to lock down edge ports and secure switch-to-switch links is an extremely attractive feature. Outside of the 802.1X protocol, there aren’t really any other ways to skin this cat. I know what you’re thinking… you don’t have to do NAC to use 802.1X… and that’s certainly true, but for a network of any size, NAC makes an 802.1X implementation easier to manage and monitor centrally and gives you more of that NAC icing we all love.

When the 802.1X-REV comes out (probably early 2009) I think you’ll see organizations that have previously blown off 1X seriously considering it for all the added security and multi-user support it will bring to the table.

#4: User & Resource Accounting
Unless you have a 3rd party solution or want to dig through mounds of RADIUS syslogs, you probably don’t have a good way to account for user authentication and accountability of resource access throughout the network. Most vendors’ NAC solutions already have pretty good logging and reporting features built in today. Depending on the solution and integration of other devices, you may even get detailed accounts of which user viewed exactly what, when and from where. This is a great selling point to organizations that are trying to follow strict regulations for accountability of financial or extremely sensitive resources. The standards bodies (IEEE, TNC framework and IETF) are coming out with more and more ways to leverage 3rd party security devices within NAC. The IF-MAP is a great example and we’ll be seeing more I’m sure.

#5: Dynamic VLAN Assignment
Lastly, but not least, I hear a lot of customers that are looking for a good way to dynamically provision attributes, such as VLAN assignment and QoS to users or devices. It makes switch configuration and management much simpler, and eliminates the need to assign port-based VLANs. The ability to leverage your existing user directory and define both broad and very granular attributes is certainly a draw, and NAC is a great way to offer that.

That wraps up my Top 5. Of course, there are plenty more drivers, both business-based or technology-based, but these are the 5 I hear most.

# # #