Spliced feed for Security Bloggers Network |
| Wiretaps we can believe in [Emergent Chaos] Posted: 13 Jul 2008 02:41 AM CDT |
| Posted: 12 Jul 2008 12:49 PM CDT |
| Links for 2008-07-11 [del.icio.us] [Anton Chuvakin Blog - "Security Warrior"] Posted: 12 Jul 2008 12:00 AM CDT
|
| Fun Reading on Security - 5 [Anton Chuvakin Blog - "Security Warrior"] Posted: 11 Jul 2008 07:57 PM CDT Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #5, dated June 11, 2008.
See you next time! |
| Simple PHP Security Library [Hackers Center Blogs] Posted: 11 Jul 2008 06:00 PM CDT sseq-lib - Simple PHP Security Library Credit: erichth Mainly meant for private and semi-professional developers who need some help in securing small php applications against some of the top-10 attacks on web software. Security increase to avoid: * XSS (Cross Site Scripting) * SQL-Injection * CSRF (Cross Site Request Furgery) * Session-Fixation * Mail-Header-Injection * File-Injection * HTTP-Header-Manipulation * Response-Splittin [...] |
| Fun AV Cartoon [Anton Chuvakin Blog - "Security Warrior"] Posted: 11 Jul 2008 11:58 AM CDT |
| Leveraging Public Data For Competitive Purposes [Emergent Chaos] Posted: 11 Jul 2008 10:37 AM CDT The Freakonomics blog pretty much says it all: The latest: importgenius.com, the brainchild of brothers Ryan and David Petersen, with Michael Kanko. They exploit customs reporting obligations and Freedom of Information requests to organize and publish — in real-time — the contents of every shipping container entering the United States. From importgenius.com. Talk about a not-so-covert channel leaking what your business is up to on a daily basis. What the Petersens and Kanko are onto is yet another unintended consequence of globalization. It makes me wonder what other sources like this are out there and accessible via the Freedom of Information Act. Similarly, as one commenter on the above article asked, how soon before people try to game the system: I wonder if something like this will lead to a rise in ‘creative’ customs declarations. Say a proxy company to take that new shipment of 22,000 digital thingies that are then immediately sold to Apple and thus mitigating the chances of someone predicting the street date of their latest offering |
| Archimedius Top 5 Report [ARCHIMEDIUS] Posted: 11 Jul 2008 07:27 AM CDT As I prepare to indulge myself with wife and kids and friends the next few days I thought I would assemble a top 5 posts report (as of July 11 2008). Also, thanks to Matt Abrams Design for the new blog look. Have a great weekend and thanks for visiting. I'll be back next week. TOP [...] |
| The big DNS issue [spylogic.net] Posted: 11 Jul 2008 05:00 AM CDT I won't ramble on about the DNS vulnerability discovered by Dan Kaminsky this week...plenty of other blogs and news sites are covering it. Yes...it's important, groundbreaking and all that jazz. However, if you want the real scoop especially if you need to convince your employer that this needs to be addressed quickly...then I point you to Rick Mogull's web site securosis.com (specifically this post) and listen to the podcast over at the Network Security Podcast which has a good interview with Dan Kaminsky. Oh yeah..Dan has a cool "DNS Checker" on his web site where you can test your own DNS servers to see if they are vulnerable. |
| The Recent History of the Future of Cash [Emergent Chaos] Posted: 11 Jul 2008 01:45 AM CDT Dave Birch has a really interesting post about The future of the future of cash: The report also identifies three key attributes of cash that make it -- still -- the dominant payment system. Universality, trust and anonymity. I'm curious about the location of anonymity in the customer mindset and I'm going to post some more about this shortly, so I'm only looking at the first two here.I want to extend Dave's assessment of what makes "trust" interesting: Trust, on the other hand, may not be such a big barrier. It's not clear to me how to disentangle trust in the medium of exchange from trust in the store of value, since people clearly use cash for both, but it is clear that a great many other tradable items can easily usurp cash once technology has acted to shift them from being a store of value into a viable medium of exchange (remember the tally sticks!) for their age. A couple of months ago we were discussing Nick Szabo's classification of commodity derivatives as a kind of near-money, but there are plenty of exant near-monies already in use around the world, including mobile phone minutes in a great many developing countries. If I lived in Zimbabwe, it would take me years to learn to trust cash more than Vodafone minutes.I think there's an important element of trust missing, which is finality. With almost all computer-based systems, payments are conditional on some complex bureaucracy deciding to credit them. For example, see Gary Leff on some deal for frequent flyer miles: Second, print everything and I mean everything. I printed the offer itself. I printed the page where I enter all the information about the rental (including my Skymiles number, etc). I printed the confirmation page. I’m saving all of those, and will save my rental receipt as well.Why does he do this? Because he doesn't trust the system. He's prepping himself to go fight its decisions. In contrast, if they handed him a bearer certificate for 9,999 miles, or $200 cash (the rough value of the miles at $.02 per) he'd be done. He'd trust those things. People used to sell things for cash on the barrelhead. When that cash was cold, hard cash, rather than fiat, print-it-yourself money, the deal was done when the money changed hands. You can't lose any more than you have in your pocket (or under your mattress). Electronic systems don't have that property, and that makes them harder to trust. You don't just have to disentangle value-store from medium of exchange. You have to estimate the value of finality. |
| Links for 2008-07-10 [del.icio.us] [Anton Chuvakin Blog - "Security Warrior"] Posted: 11 Jul 2008 12:00 AM CDT |
| New Firmware [Errata Security] Posted: 10 Jul 2008 10:02 PM CDT Thanks to lifehacker, http://lifehacker.com/398280/iphone-20-software-update-unofficially-available, My iphone is now running te 2.0 firmware. |
| Need MORE Proof That I am Popular in UK! :-) [Anton Chuvakin Blog - "Security Warrior"] Posted: 10 Jul 2008 06:41 PM CDT As I said before, my blog was nominated for ComputerWeekly.com blog contest in UK. It looks like I made the final list, so feel free to vote for me in this final stage. |
| Pre-post on "Logging: Day 1" [Anton Chuvakin Blog - "Security Warrior"] Posted: 10 Jul 2008 05:43 PM CDT Pre-announcing blog content is a shitty idea, in general. However, as I am writing this piece on "Log Management: Day 1" (obviously, inspired by this and this here), I hear that more and more people are thrust into a situation where my piece will be of huge value, thus this pre-announcement. So, if you are given a task to "tackle logs" for your organization, where should you start? What should you do first? Even, how do you decide what to do first? All this and more - in my upcoming piece next week. |
| Posted: 10 Jul 2008 04:42 PM CDT I was interviewed by SC Magazine's Dan Kaplan on the value of education in the security industry and its associated interpretation on both the west and east coast. |
| The the DNS patch [Phillip Hallam-Baker's Web Security Blog] Posted: 10 Jul 2008 03:47 PM CDT In the past 24 hours I have received a lot of queries on the reports of the major DNS security patch. Since this is not my area of responsibility I asked Matt Larson, our DNS specialist to comment, here is his reply: I'm aware of the vulnerability and know the details. It is not broader than DNS cache poisoning and only recursive name servers are vulnerable. These are the servers run by enterprises and ISPs to resolve DNS lookups on behalf of their employees' and customers' computers. Recursive name servers do the "heavy lifting" of DNS resolution by tracking down answers in authoritative name servers. Because recursive name servers cache responses they receive to speed up subsequent lookups, they are potentially vulnerable to bad information getting into their caches, via an attack called "cache poisoning". The important message is: for customer-facing services, VeriSign runs only authoritative name servers, not recursive name servers, and we are therefore completely unaffected by this vulnerability. In short, core DNS is not affected (the root, major TLD servers). But Matt did also point out that the issue does affect enterprises and ISPs that run local recursive DNS servers and that it is important that these are appropriately patched or upgraded. |
| What doesn’t work… [Ascension Blog] Posted: 10 Jul 2008 03:30 PM CDT A friend of mine passed along an email he received from an information security vendor today. The vendor had inquired as to whether or not my friend was still interested in his company’s product. When my friend thanked him for his time and explained that they had chosen to go in a different direction the vendor responded: (again paraphrased to protect the guilty) I thought we didn’t have a chance since I wasn’t able to speak to anyone other than you. Based upon common experience, I think you will find the direction you’ve chosen to be extremely expensive with relatively little return. But best of luck… Translation: Yeah, I knew you weren’t all that intelligent when you didn’t agree that my product was the best thing since sliced bread. If you’d have let me speak to someone with half a brain I’d have probably gotten the sale. You just don’t realize that you don’t really need what you decided to buy but like I said, you’re a moron so go figure. Now I’m no rocket scientist but giving a potential client backhanded “advice” isn’t going to endear yourself to that client. Even if the potential client is lacking in reasoning ability, you never tell them that. The sale that fell through today may very well be the sale that comes through tomorrow. This is the problem with product vendors. Many of them are lifelong salesmen and do not really have a clue as to what goes on in an information security department. These are the guys from the snake-oil school of sales: they tailor your problem to fit their solution as opposed to trying to really understand the problem. They don’t want to solve your problem, they want to sell their product. Now I know that this is a general statement and that there are some good sales guys out there. I’ve actually had the pleasure of meeting a few. There is one guy that I wouldn’t hesitate to call even though his territory is on the West Coast. (I’m on the East Coast.) The problem is that the good ones are few and far between. |
| Posted: 10 Jul 2008 02:44 PM CDT Here is an issue that everybody and their dog (and, likely, their dog's fleas :-)) is confused about: What does PCI DSS Requirement 2.2.1 ("Implement only one primary function per server (for example, web servers, database servers, and DNS should be implemented on separate servers)") mean in virtualized environments? Is it "one function per VM instance" or "one function per physical server?" I've heard reports of QSA interpreting it either way, which means that millions of dollars of IT investments might be at stake. Here are some arguments that I've heard about:
|
| Posted: 10 Jul 2008 02:41 PM CDT I was recently involved in a discussion over the different terms used to describe what we do? Information Security (IS), Information Assurance (IA), or Information Risk Management (IRM). Some very interesting points and observations came out of that discussion so I thought I’d echo them here. A colleague of mine, who also works as an Information Assurance (IA) professional (DoD specialty), argues that the CISSP certification has “absolutely nothing to do with IA.” He is of the opinion that Information Security is not Information Assurance and sees “no similarities” at all (ummm… none?). Anyway, from a DoD 8570 perspective, the IAM (managerial) level II and III are required to have the certification while none of the IAT (technical) levels are required to have the CISSP. This started a discussion that went in two main directions - whether the CISSP certification is useful in both the technical and managerial realms (I won’t touch on this here) and whether or not Information Security (IS) is a subset of or has anything to do with Information Assurance (IA). There were several great posts to this discussion. One was by John Graham (MSIA ‘04): Although the DoD has ‘coined’ the phase Information Assurance, in my opinion the concept certainly is broader than information security, and information security is a subset of the information assurance space…knowing and understanding the concepts required for the CISSP only strengthen the Information Assurance professionals tool kit… And I have always found it interesting that most organizations tend to initially focus on technical controls, then gain the understanding of the required linkages to process and governance needed to actually implement and maintain the controls. Sharon Mudd (MSIA ‘08) took the concept even further. I agree with John. To expand on that, in my view the entire space is going through a maturation process. What was once Information Security (focused strictly on IT) evolve into Information Risk Management (allowing it to broaden a bit) and is now heading towards Information Assurance. Each evolution incorporates what was there before and enhances the importance of getting out of the InfoSec silo and into the other areas where it runs into business processes/needs(or government, or whatever other entity you’re working with). and What was the original foundation of InfoSec seems to be what we’ve been referring to as Security Operations - or - the day-to-day hands on the firewalls/IPSs/etc. work that must be done even monitoring and incident detection can fall into this category. Where I think it goes over the wall to a risk management activity is when you start trying to understand what the alerts mean in context of your business functions and managing the issues from a cost/benefit or risk/reward perspective. I believe the term “evolution” in this context is key. One of the things that I have enjoyed about being a consultant over the years is the variety of environments and networks that I’ve been privileged to become acquainted with. Most of the time the issues that I’ve come across had very little to do with the technology. Most technology issues were symptomatic of deeper alignment issues. Many of the highly specialized (or more tactical) activities that IS “grew up with” have now begun to be relegated back to the network and infrastructure departments. Our role has evolved into a strategic role that bridges business units. IT, and by extension IS/IA/IRM, has been the one department that is typically siloed off from the rest of the company in terms of being fully integrated into business operations. This is most likely do to the fact that IT basically began as a support function not much above the mail room in importance. The companies that have seen the advantage of integrating IT and IS into their strategic planning process have gained a commanding advantage in the workplace. Once you achieve an alignment with the business objectives, IS/IA/IRM projects are easier to sort out and prioritize in terms of their overall value. As we all know this requires that both the business units and IT cooperate in achieving the common goal. One key aspect of this is the use of a common taxonomy. In the end, whether we call it information security, information assurance, risk management or “skippity do” doesn’t really matter all that much as long as we achieve the ultimate goal of bringing value to our employers. The terminology may be determined by the sector in which were working, such as the DoD example, or it may be something that we can influence. I believe that we must learn the language of business. Business won’t learn the language of information security - that is what they hire us for. The approach that requires management to learn “our language” is doomed to failure. Whatever the case I’m more of an advocate of using the terms that most clearly conveys the concept to my audience. |
| Wireshark "TurboCap" [Errata Security] Posted: 10 Jul 2008 12:13 PM CDT I just noticed that CACEtech is now selling a sniffing adapter "TurboCap for Windows. (CACEtech is the company that funds Wireshark development - and if you are a cybersecurity geek, you should have experience with Wireshark). This product addresses the problem that operating-systems (Windows, Linux, BSD, et al.) are not optimized for sniffing packets. Thus, if you wanted to sniff a fast network with Wireshark, you'd be lucky sniffing at a rate of 300,000 packets per second. This product claims to allow sniffing at 3-million packets per second, which is the max theoretical speed for full-duplex gigabit Ethernet. This product addresses the problem with a custom driver. You cannot use this card for normal networking. Although it physically is a network card, it will not appear as one of the network cards under Windows. It is a special "sniffing" card instead. It will only be available for custom sniffing applications, such as Wireshark. The first product that replaced the network stack with a custom sniffing driver was the Network General "Sniffer"™ back in the 1980s. This is the product that gave us the name "packet-sniffer". It was the first to achieve "wire-speed" sniffing performance. Many sniffing products have since used this idea. I used to work at Network General. When I founded my own company and created the BlackICE intrusion-detection system in 1998, I likewise used this concept. We wrote a custom sniffing driver for the 3c905 hardware. This happened to be the chip used in Dell notebooks of the time. The upshot of this was that my Dell notebook could do wirespeed 100-mbps intrusion-detection while other products at the time struggled at 10-mbps. This was an unbelievable speed back in the day, although custom drivers are more common now, so most intrusion-detection products now support wirespeed. When writing a custom driver, or tweaking the existing drivers for better speed, there are a number of issues that you address. BUFFER SIZE Standard network drivers use tiny buffers, often a mere 64k. You want a lot more for a sniffing application. You might allocate a 100-megabyte buffer within the driver for holding packets. FRAGMENT SIZE In order to fit variable sized packets into a tiny buffer, most cards will fragment the packets in to 64 byte, 128 byte, or 256 byte chunks. The network driver must then reassemble the fragments back into whole packets before sending them up the network stack. Note that this is a wholly different sort of fragmentation at the hardware level unrelated to the fragmentation that occurs at the TCP/IP level. A good choice for fragment size is 2048 bytes. It's large enough to hold standard Ethernet packets without needing reassembly. Only GigE jumbo frames would need to be reassembled. POLLING INSTEAD OF INTERUPTS The operating-system stack is designed so that incoming packets cause a hardware interrupt. This causes the operating system to halt its current task, run the driver code to deal with incoming packet, then resume. Handling an interrupt is efficient if there are few of then (less then 10,000 per second), but extremely inefficient if there are many. Sending 3-million interrupts per second at a typical operating system will cause it to lock up. The alternative solution is "polling", where the software constantly tries to read the next packet. This means that there is no overhead from interrupts if the packets are arriving very fast, but means that the CPU is pegged at 100% utilization even if there is no traffic at all. A hybrid method is to poll on a timer interrupt. In this method, you set up a timed interrupt (such as 10,000 per second), then poll the card to see if any packets have arrived since the last interval. DATA TRANSFER There are two ways of getting packets off the network card into memory. The first is "programmed input-output". In this mode, the CPU reads the bytes from the network chip, and then writes them into main memory. The second method is "direct memory access (DMA)". In this method, the network card writes the packets directly to memory, bypassing the CPU. The CPU still needs to be involved with DMA. It must tell the adapter where buffers are in memory. The driver must continually refresh the list of free buffers. Thus, as the code processes incoming packets, it will free up those buffers and send them back to the network hardware for reuse in DMA. KERNEL-MODE TO USE-MODE TRANSITIONS In much the same way that handling an interrupt is expensive, there is a lot of overhead in transferring control from driver (which runs in kernel-mode) to the application (which runs in user-mode). You would likewise lock up the system trying to do this for every packet at 3-million packets per second. The trick to get around this is to map the buffer in both kernel space and user space. In this manner, the user-mode sniffing application can read packets directly from the buffer without a kernel-mode transition. CPU BUDGET Consider a 3-GHz CPU trying to sniff packets on a full duplex Ethernet at 3-million packets per second. Simple math shows that you have only 1000 CPU cycles per packet. That is your "budget". This budget gets used up pretty fast. The problem isn't necessarily the number of instructions that can be executed (CPUs can execute multiple instructions per cycle), but memory access. The CPU can access a register in 1-cycle, first level cache in 3-cycles, second level cache in 25-cycles, and main memory in 250-cycles. In other words, if the software attempts to read memory, and it's not in the cache (a "cache miss"), it must stop and wait 250-cycles for the data to be read. Thus, a 1000-cycle-per-packet budget equates to a 4-cache-miss-per-packet budget. The packets are DMAed by the driver into memory, but not the cache. Therefore, reading the first byte of a packet will result in a cache miss. This leave only 750-cycles remaining. In addition, the header information (packet length, timestamp, etc.) are located in a different place in memory. This will also cause a cache miss, leaving only 500-cycles left. Multiple CPUs must be synchronized with a full memory access, which has the same cost as a cache miss. This leaves 250-cycles left to process the packet. If you do something like a TCP connection table lookup, you've probably got another cache miss. These leaves 0-cycles left to process the packet. Thus, we've quickly exceeded our CPU budget without actually doing anything. With most drivers, you can locate the packet headers with the packet data. By combining them into the same location, they can be read together without a separate cache miss. CPU's have a pre-fetch instruction. The packet-read API can be implemented so that whenever the software reads the current packet, it "pre-fetches" the next packet into cache. Thus, the headers and data will be available next time without a cache miss. If you use a ring buffer and a producer-consumer relationship, you won't need to use a traditional memory lock to synchronize the driver with the application. If you are even more clever with your sniffing API, you pre-fetch several future packets, and you allow the application to peek at the next packet allowing it to pre-fetch its TCP connection entry. Putting this all together, I've proven that you'll need at least 4-cache misses to process a packet, and thus handling 3-million packets per second is impossible. Then, I've shown tricks to show how you can get around this and process a packet without any cache misses. OTHER TRICKS There are a long list of other optimizations you can do. For example, you'll want to align your buffers on cache-line boundaries. You'll also want to set the processor affinity flags so that the driver uses one CPU core while the user-mode process uses the remaining cores. CONCLUSION CACEtech claims "wirespeed" performance, which implies 3-million packets-per-second. I don't know if they've implemented all these tricks. Their cards are a little pricey ($900 each), so I'm not willing to buy one just to play with it. However, for anybody running network tools like Wireshark or Snort, they should logically give a huge boost in performance. |
| What have we achieved so far? [GNUCITIZEN] Posted: 10 Jul 2008 11:56 AM CDT  In this post I would like to summarize some of the things we (GNUCITIZEN) have achieved so far. I am writing this post purposefully for myself, and for our group and I hope that we can use it as a base reference point to go even further. When I look back, it looks like we’ve done a lot, yet it still feels that we could have achieved so much more. Through, time and money, but mostly time, have always been problems and I wish we had an army of drones with hearts and brains to help us out in times when ideas burst out and motivation and passion are at their peak. Often that is exactly the case and I realize how important to stay focused is. Being focused is not a skill bur rather a human characteristic which fits some. So, let me layout what we’ve got so far: GNUCITIZEN .ORG/.NET/.COMWe’ve branched out into tree separate projects for our convenience since each one of them serves different purpose. The blog (.ORG) had an excellent two years of viability and have influenced the info sec field, but not only, in some positive ways. We’ve had a couple of good and bad experiments and we’ve learned a lot. This type of experience money can’t buy and I am quite happy that I had to go through all the hustle in times when hustle was I’ve got. We are progressing here. I haven’t blogged much lately due to the fact that I had to put my attention somewhere else, but I and the group are cooking some good things for the near future. We are still looking for good people who would like to express their thoughts on GC. With the current user base, page rank (7) and an exceptional monthly traffic, I would say that we have one of the best scenes where you can develop you talent and get a good exposure. So, if you are interested, let us know, as always, from our contact page. The .NET domain turned into a hub for all our external projects regardless whether they are security related or not. The domain is barely visible to our visitors (on average 50 unique visitors per day) but I feel satisfied when I go there and I see a bunch of good ideas shaping right in front of my eyes. The .COM is yet to be fully implemented. Stay tuned for that one since we’ve prepared some awesome stuff for the future. HakiriThe reason I’ve started the Hakiri project was because I felt that I need to express my thoughts on art, design, culture, sociology and other topics very dear to my soul, on a separate domain. GNUCITIZEN has just started to shape into something more then a personal blog and I thought it is the right thing to do to keep personal development things on a separate place. That move caused all sort of good ideas to emerge but I thought I should write them down instead of jump start implementing all of them. At the moment, Hakiri is developed when inspiration and free time is available and that pretty much sums up to once or twice per month, which is not enough but it I am taking it easy. Again, you are welcome to join, and I think that this project has a lot to offer. Spin HuntersI am partnering on this initiative and I must say that this is such an awesome idea. Spin Hunters, if you don’t know yet, is an organization which deals with thing such as Black PR, Reputation Security, and other things from the black and white arts of the PR industry. All of this is stirred well with a solid those of Infosecurity. This is what I call a wonderful mix of talent and ideas. What can I say? It does well! SecUrlsI thought that the info security industry really needs a place where people can glance through what is going on a daily even hourly basis. I am subscribed to hundreds of feeds and most of them are practically useless. Yet again, I wanted to solve problem for myself and with that hoping to solve a problem for others, I’ve setup the first version of SecUrls which was pathetic. I even installed ads and although the site was down almost a month (a blank page), I’ve made $14 USD, go figure. I am quite happy with the current version of SecUrls although I realize that there is so much more it could be in the future. We’ve got good sources, good filters on place and some cool algorithms to match news articles with awesome Flickr photos - a mashup at its best. For fun, there is even a twitter feed which summarizes what security pros are twittering about. Useful if you don’t want to setup your own Twitter account. House of HackersNow this is the project which have an infinite number of potential developments. It could turn into anything. I have no idea where it will go but I had promised myself to buy a domain and purchase Ning’s premium services if we reach 1000 members. Today, HoH community is close to 5000 but non one have found a way to make use of it yet. Well, I have a few ideas but I have no power on whether they will be accepted. It is a community thing. But if you have an idea and you need people, this is the right group to approach. There are some quite interesting characters there from around the globe (yes, HoH is truly international, check the groups) who I believe make an excellent fit for all kind of useful, cool and interesting projects. BlogsecurifyWork in progress! I think that this type of service is needed. Blogs are essential business tool today and they are important not only for individuals but also for companies and organizations. Therefore, keeping them secure is very, very much a must. Blogsecurify is what we’ve prepared to tackle this problem. I am quite proud of the testing engine, which is written in python and can be used for all kinds of security related projects that will be hosted on Google’s cloud. If you want to join the initiative, please ask. Websecurify/NetsecurifyLike Blogsecurify but for Web and Net. Nothing here yet but I think that these are good ideas. Suggestions are welcome. If you want to join these initiatives, please ask. AdsosimpleOk, this is what I’ve been busy with lately. It is not security related but it felt like a fresh breeze after doing so much security work and I really needed a service of that type. Adsosimple is a simple service which solves a very fundamental problem - making ad revenue without going through advertising platforms such as Adsense. We were planning to build inline ads for Blogsecurify in order to keep the service free. Through, Adsense is not suitable for that kind of thing, neither other ad platforms I’ve been researching online. So, I thought to build one myself. Adsosimple is the result of my efforts. While building it, I’ve learned a lot about hacking paypal. You will be surprised how easy it is to buy goods from sites without paying a thing. At the moment, Adsosimple is in sandbox beta stage. This means that you can only use the PayPal sandbox only to pay for things, which does not use real money. That will change once I am comfortable with the way the system works. Mini Security Related ProjectsWe’ve got some many of them it is not even funny. :) Check our projects pages. External EntitiesWe’ve got article across some of the best information portals online. I’ve been personally involved with contributing to several books. We’ve got a Wikipedia page, Technorati, Facebook, YouTube, Twitter exposure. It is really hard to summarize everything.
|
| You Are "A Security Idiot" If ... [Anton Chuvakin Blog - "Security Warrior"] Posted: 10 Jul 2008 11:22 AM CDT ... you:
To be explained later :-) |
| Will Cloud Computing Rain on Microsoft? [ARCHIMEDIUS] Posted: 10 Jul 2008 10:40 AM CDT A recent Computerworld blog by Preston Gralla exposes a Microsoft weakness when it comes to competing with Google and others in cloud computing: It’s understandable that Microsoft is leery of offering Microsoft Office as a hosted service, because it could cannibalize its substantial Office revenue. But if Microsoft doesn’t do the cannibalizing, someone else will, especially [...] |
| Posted: 10 Jul 2008 09:37 AM CDT  I found myself this week explaining to people the difference between a real threat and a perceived threat. |
| You are subscribed to email updates from Black Hat Security Bloggers Network To stop receiving these emails, you may unsubscribe now. | Email Delivery powered by FeedBurner |
Inbox too full?  Subscribe to the feed version of Black Hat Security Bloggers Network in a feed reader. | |
| If you prefer to unsubscribe via postal mail, write to: Black Hat Security Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610 | |
No comments:
Post a Comment