MacOS X vpnd vulnerability disclosed
A local buffer overflow vulnerability in Apple MacOS X was disclosed on he vulnwatch mailing list today. The vpn demon, suid by default, can reportedly be exploited to execute arbitrary code by a local nonprivileged user.
CVE ID CAN-2005-1343 has been assigned to this. Apple Security Update 2005-005 fixes this and other issues. http://docs.info.apple.com/article.html?artnum=301528
XSS from unexpected places
A friend of the ISC passed along an email discussing code insertion showing up in whois records. Whois servers maintain contact information for registered domains and ip address allocations. Through the use of '<script>' tags, code can be executed by browsers when viewing those records.
Some ramblings on storage
Someone emailed asking for recommendations on storage of security logs data and I though this might be useful for others facing similar planning challenges -
We keep data around for three reasons: Someone important says we need
to, we are going to use the data later, or we just like having it or
are too lazy to clean it out. A major goal in any storage project
should be to get that down to the first two. Although I haven't
gathered empirical evidence to support this, I'll venture that a
large percentage of our storage challenges are the result of number
three. That can most readily be dealt with through self discipline
and/or draconian quotas. Let's examine the first two a little more.
First, we need to contend with regulatory obligations. In the case of
SOX or HIPAA, there are plenty of folks making money by helping
companies out with compliance, since there are fairly healthy data
retention and security requirements with both. For my research, I am
required by the funders to keep all raw data on hand for at least
three years - we are building yet another data library at this time.
You may have other requirements - speak with your compliance officer
so you can be sure to place the blam^H^H^H^H^H^H^H^H^H^H^H^H^Hcover
all the bases.
The secondary concern is usefulness. The usefulness of a record
depreciates with time, as its contextual relevance decays. In other
words, as a piece of data becomes less likely to be correlated with
new events, its (other than compliance) value shrinks. If you are
doing no analysis at all, then the usefulness of any logs is nil.
If you see something in your firewall logs and wish to correlate with
the past month's worth of logs, they had better be available. Without
anyone doing such analysis, the month of logs really isn't all that
useful. A grocery store owner probably doesn't need to keep those
firewall logs very long, same goes for her video surveillance tapes
(she'll know prety quickly whether or not those need reviewing!) Her
stock ledgers and employee records are likely to be held onto for
years, as there may be government bodies who say so, or she
recognizes the efficiency gains that she can reap by correlating
data and trending "shrinkage".
Aggregate analysis of data (bandwidth percentiles, IDS alert class
frequency, storage utilization, etc.) requires raw metrics be retained
until that aggregation takes place. After that, the raw data can be
discarded if you will not be doing anything further with it. Any
meta-analysis using the monthly aggregates will neccesitate storage &
retrieval of those aggregates, until *they* are no longer needeed. And
so on, and so on. Essentially, it is a distilling process, where you
boil off what isn't needed any longer, while the essence of it remains
available for consumption or later cooking.
With network traffic, this distillation process often starts at the
router, returning netflows rather than raw packet data. In the case of
IDS, often raw packet captures are fed through some rule-based engine
and its findings are reported, sometimes including the specific
libpcap records that are related to an alert event. Once you have this
data you then draw pretty graphs, give your monthly briefing, and earn
a nice bonus. Then you can discard the raw data, keeping the graphs
for the quarterly summary. However, if Kirby from accounting is
colorblind and you are likely to be asked to recreate them as bar
graphs instead of pie charts, you may want to hang onto the raw data a
little longer, at least until after the quarterly.
I personally am a packet geek. I love to roll around in them and get
dirty as much as possible, but I recognize their value diminishes
pretty rapidly, so I generally go with full packets at first, then
reduce them with editcap to 128 bytes after 48 hours, then to 48 bytes
after a month. The statistics pulled from them I keep around for a
year, then they are overwritten.
Back to your question, "any pointers?". I advise a strategy along
A few general notes:
- Software compression may seem like a good idea, but in production
more aggressive algorithms kill your performance. Go for hardware
compression on your LTO drives for offline stuff.
- For large volumes of integrity-critical data, take a look at some of
the new CAS and hard-disk WORM technologies. Expensive, but worth it.
Oh, yeah - don't get too wrapped up in the MD5 vs. SHA1 arguments.
Some CAS vendors will claim to be "more secure" since they use SHA1.
Yes, there is an academic proof for MD5 collisions, but in reality
your data will be long-ago worthless by the time someone can exploit
that on a real storage system.
- End to end security is essential. Don't forget about offline and
offsite storage, including physical site and transportation. Don't let
a disgruntled minimum wage courier be the weakest link in your
organization's data confidentiality. I've seen it happen.
May 5th 2005
|Thread locked Subscribe||
May 5th 2005
1 decade ago