Earlier this year I committed to attending at least one conference. At the start of this month I attended a small UK information-security gathering — a one-day event organised by a regional chapter of the British Computer Society, held in a conference room above a Manchester pub. About 40 attendees, six speakers, a long break for lunch.
I did not speak. I attended. The point was to break out of writing-in-isolation and meet some of the people I have been corresponding with by email for over a year.
This is the writeup. Kept short because the value of the day was not the talks; it was the conversations.
The talks, briefly
Six talks. In order:
A retrospective on the Mafiaboy attacks by someone who had been on a UK ISP's response team during the February events. Substantively similar to my own writing, with operator-side details I had not had access to. The most useful single new fact: most of the upstream filtering applied during the attacks remained in place for months afterwards, providing a quiet ongoing reduction in baseline DDoS traffic.
A live demonstration of Sub7 and Back Orifice 2000 by an academic researcher. The demonstration was effective — most of the audience had read about these tools but had not seen them used. The point made was that the tooling is substantially more polished than the typical security-press coverage suggests.
An overview of the emerging UK Computer Misuse Act amendments. Specific changes proposed: stronger penalties for denial-of-service offences, clarifications around what counts as authorised access, provisions for international cooperation. The talk was given by a barrister; the technical level was modest but the legal context was educational.
Audit findings from a small consultancy, anonymised. Five anonymised case studies of small UK businesses with significant security gaps. The case studies were familiar — same gaps in the same patterns I have seen in my own consulting — but the talk was useful for confirming that the patterns I see are not unique.
An introduction to the new Snort 1.7 by someone at the Honeynet Project's UK chapter. Substantively similar to what I wrote a fortnight ago, with some good operational tips I will fold into my own setup.
A panel on small-business security, with a few practitioners discussing what advice actually works versus what advice sounds good but cannot be implemented. The most useful single observation: small businesses, like the consultancy I helped this month, do not have the scale for proper security investment but cannot afford the cost of the alternative either. The discussion did not produce a clear answer; it did clarify the dilemma.
None of the talks were dramatic; all of them were competent. The level was about right for a regional gathering — practitioners exchanging working knowledge rather than researchers presenting novel findings.
The conversations
The value of the day was the unstructured time around the talks. Several conversations I will remember:
A long talk over lunch with a sysadmin from Manchester University. They have been running a Honeynet-style deployment for academic research and have been generating data for two years. We compared notes on capture patterns; their data and mine were broadly consistent (which is a useful confirmation that my single-host observations are not idiosyncratic). They invited me to visit their setup. I will probably take them up on that.
A brief conversation with a security consultant from a London firm, who has been reading my notebook for over a year. They asked about the forensic-readiness post specifically — they were preparing similar material for an internal training and wanted to discuss the structure. The conversation went on past their next session and into the lunch break.
A surprisingly long discussion with a small-business owner who had attended out of concern about their own infrastructure. They are not a technical person, but they had read my notebook and had some specific questions. The conversation revealed that the gap between my notebook's audience and the people who actually need basic security advice is wider than I had appreciated. The notebook is written for people who already work in this field; the people who need defensive guidance most are people who are not yet in the field.
This is something I have been thinking about since. There may be a separate, simpler piece of writing I should be doing for the smaller-organisation, less-technical audience. The notebook serves a particular audience; it does not serve everyone who could benefit from it.
A short conversation with someone from Cisco's UK office, who I had been on the PIX configuration thread on a vendor mailing list with. We compared notes on what we each disliked about the product. The conversation was honest in a way I would not have expected from a vendor representative. The product is genuinely behind in the areas I had identified; the vendor knows it; the roadmap addresses some of it but not enough.
What I learned about the UK security community
The community is smaller than I had thought. About forty people in a conference room is not a small fraction of the practising UK information-security professionals. The handful of people I had heard of were all there or had been recently. The expertise is concentrated.
The community is more collegial than I had thought. Despite competitive pressure (most attendees represent firms that compete commercially), the technical conversations were open and detailed. The norms of academic security research — sharing findings, discussing failures honestly, comparing notes across organisations — are operationally present in the UK practitioner community in a way I had not expected.
The community is more London-centric than I had thought. Despite the Manchester venue, most attendees were either Manchester-based or had travelled from London for the day. The other UK regions were thinly represented. There may be opportunity for similar gatherings in other regions; certainly worth thinking about.
The community is less diverse than it should be. Of forty attendees, three were women. The age range was concentrated in the 25-40 band. The technical-versus-policy split was about 70/30, which felt right for a security-practitioner gathering. None of these observations are flattering to the community; the under-representation is real.
What I am going to do differently
Four things, in roughly increasing order of effort.
Attend more events. Probably one a quarter rather than one a year. The cost is modest; the value is substantial. The discipline is to actually do it rather than letting writing absorb the time.
Talk to non-experts more deliberately. The conversation with the small-business owner highlighted a gap in my own writing. I am going to think about whether there is a complementary piece of writing for that audience, or whether to occasionally write notebook posts targeted at less-technical readers.
Engage with the BCS or similar professional bodies. The structure provides an organised community that is doing real work. I should at least be a member.
Consider speaking at one of these in 2001. The talks I attended were competent but not dramatic; the bar to entry as a speaker is not high. I have been writing for two and a half years; I have specific things to say; the format would be a useful exercise. I am not going to commit to it yet, but I am going to think about it seriously.
A small reflection
The day was enjoyable in a way I had not expected. Reading and writing are intrinsically solitary; the conversation about reading and writing is intrinsically social; the gap between the two activities is larger than I had appreciated.
For anyone reading this who has been writing about technical work in isolation: go to a conference. Even a small regional one. The technical content of the talks may not be new to you. The conversations will be valuable in ways that are hard to predict and hard to obtain otherwise.
More on the year as it develops. Back to technical content next.