LogBlog

Cloud Computing and Log Management

Since my posting on public and private clouds, I have been getting email from people asking about the specifics of how LogLogic’s products really participate in “The Cloud”.

LogLogic’s architectural premise is to handle the ingestion of logs from unknown sources, and to have flexibility as to the kinds of devices, logs or target locations. Additionally, we even offer a unique feature allowing automatic identification of log sources. This is where the system can match a stream to a type of log for agile reporting and normalization.

We’ve also designed our licensing model to embrace such agile or fluid computing models, and not be tightly licensed to a specific target, device or log source. In this way we’re not only the leader in Log Management, but we’re also enabling many ESSP, MSP and cloud enabling Telco clients to have flexibility in their logging demands. This is being done all while tracking data that’s dynamically moved around their asset pool.

With LogLogic, we leave no log left behind, and there’s no cloud too opaque.

Posted by Guy Churchward on December 14, 2009 in Cloud Computing | Permalink | Comments (0)

Why the Public and Private Clouds Don’t Mix

By Guy Churchward, LogLogic CEO

Cloud computing tops Gartner's “Top 10 Strategic Technologies for 2010.” They define a strategic technology as “one with the potential for significant impact on the enterprise in the next three years.” Gartner is somewhat right here. The fundamental problem I have is that the industry has bucketed anything that can be loosely defined as cloud, virtual, consolidatory, or anything on the network in the same term being cloud. All of us loosely interchange public, private and cloud services to our whims which quite frankly confuses the general public.

To be fair, Gartner does predict that through 2012, “IT organizations will spend more money on private cloud computing investments than on offerings from public cloud providers.” This is great, but I long for the day where this nebulous or opaque term can be segmented into public clouds, private clouds and more importantly ITaaS. This is not only a trend for 2010 but has been feverishly worked on through the last 24 months. It has been wrapped up in a pretty bow and proclaimed as ‘cloud’ for the convenience of propping up the ‘invisible dog leash’ fad-based early startups that infest the wannabe public cloud offerings (or so they think).

Getting back off my hobbyhorse, there are two primary reasons (amongst many) why the enterprise will not make major strides towards the public cloud– lack of visibility and multi-tenancy issues which cloak the real concern over critical data security.

Lack of visibility

The public cloud is opaque and lacks a level of true accountability that will paralyze any enterprise account from releasing their prized data assets to a set of unknown entities. Look at the value proposition - no one consuming the service has visibility into the infrastructure. The provider themselves aren’t looking at the infrastructure. Are SLAs relevant? And if so, who can enforce or even monitor them?

The public cloud has received so much buzz in large part because it professes to offer significant cost savings over buying, deploying and maintaining an in-house IT infrastructure. While this is massively appealing, it doesn’t answer any of the fundamentals of Quality of Service, network and data security to name a few. Imagine the concern of opening up your internal systems with a direct pipe into the ‘cloud’. This is the equivalent of leaving your data center door open, while your data center adjoins a ‘how to hack systems’ symposium .

Multitenancy Issues

The second reason why businesses of any real size will not make the leap to the public cloud is: Multitenancy. Wikipedia (the font of all knowledge) defines multitenancy as “a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants).” In other words, many people using the same IT assets and infrastructure.  

So here’s the rub, EC2, Google, etc., provide true multi-tenancy but at what cost to compliance and security? What about such hot topics such as PCI or forensics? How safe are the tenants on a system? Who is on the same system as you, a hacker or perhaps your dearest competition? How secure is the isolation between clients? What data have you trusted to this cloud? If you buy the argument, it will be your patient records, payroll, client list, etc. It will be essentially your most important data assets. I have to think this would be a good test of data asset Darwinism.

Cloud computing needs to cover its assets

Until the public cloud can provide visibility all the way down to the IT infrastructures most simple asset – logs - enterprises simply won’t risk it. To be deployed properly, a public cloud needs to understand logs and log management for purposes such as security, business intelligence, IT optimization, PCI forensics, parsing out billing info, and the list goes on.

Until then, in the grand scheme of risk mitigation, enterprises will fear the cloud and per my recommendation, segment public cloud from ITaaS in a private cloud. It’s a shame but as we’ve clubbed all the terms into a single bucket. It turns all the lights red and in fact there’s a tremendous value in cloud computing. But public clouds and enterprise computing are a world apart and should be treated as such. And there are whole rafts of risks to be consider along the way.

Posted by Guy Churchward on December 08, 2009 in Cloud Computing , Log Management & Intelligence | Permalink | Comments (0)

Podcast: IT systems analytics become more crucial as cloud and SaaS adoption raises complexity bar

Read a full transcript of the discussion. Find it on iTunes/iPod.

Software-as-a-service (SaaS) and cloud computing are changing the nature of IT systems’ performance requirements and heightening expectations for end users from online applications and services.

Increasingly, an extended level of visibility, management, and performance will apply to those serving up applications as services, regardless of their hosting origins or models. The more the apps and services fulfill a need, the more the users will expect even better results and performance.

In other words, the more these organizations succeed, the more they need to scale, leverage virtualization and cloud infrastructure methods, embark of service oriented architecture (SOA) and then keep all the trains running fast and on time. Using the latest tools and analytics — the equivalent of business intelligence (BI) for IT — on the systems and across the gathering complexity becomes essential.

To learn more about how systems log tools and analysis are aiding providers of cloud and SaaS, I recently spoke with fellow blogger Phil Wainewright, an independent analyst and director at Procullux Ventures, and SaaS blogger at ZDNet and ebizQ, as well as with Jian Zhen, senior director of product management at LogLogic.

Posted by on December 17, 2008 in Cloud Computing , Log Management & Intelligence , SaaS | Permalink | Comments (0)

Challenges of Enterprise Cloud Computing

[ Originally posted at OnSaaS ]

Today, the major use of cloud computing for enterprises are still in its infancy (heck the whole cloud computing space is in its infancy). Most enterprises use cloud computing for testing, development and other peripheral tasks. However, most, if any, are using the clouds for production use. This is fairly similar to the virtualization space, where early use of the virtualization technology are for testing and development. Ten years later, we are seeing more and more enterprises adopt virtualization for production use and virtualization has become main stream.

What are these challenges for enterprise cloud computing? I have tried to summarize them here (in no particular order).

Data Governance

I've written extensively about the need for data governance in previous posts. In essence, enterprises have a ton of sensitive data that requires access monitoring and protection. Data (and information generated from the data) is the life blood of many enterprises, the loss of control will not be acceptable. Whole markets (read: DLP) are created to protect the enterprise data and information. On top of all that, enterprises must comply with many of the regulations that require data governance. By moving the data into the cloud, enterprise, for now, will lose some capabilities to govern their own data set. They would have to rely on the service providers to guarantee the safety of their data.

I hate to invoke the ILM acronym but much of data governance is about

So who's tackling this problem? As far as I know, nobody is and nobody really can except for the service providers themselves. It is really up to the service providers such as Amazon, Google and Salesforce to provide guarantees that customer data are safe and access to data are restricted and protected.

Manageability

There are some great IaaS/PaaS out there, including Amazon's web services (S3, EC2, EBS, etc), Google's App Engine, Salesforce's Force.com, Joyent, etc. However, most of these are raw infrastructures and platforms that do not have great management capabilities. This is not unusual. Throughout computing history, raw capabilities will generally appear on the market first, then management of these raw capabilities become a differentiator when competition heats up. Just look at the blade server and virtualization spaces as these are great examples of that trend. The hypervisor was the key technology that enabled enterprise virtualization; however, that piece is now being given away (see VMware's ESXi) and management capabilities becomes the main differentiator.

Cloud computing is no different. An example of missing management capabilities for cloud infrastructures is auto-scaling. Amazon EC2 claims to be elastic; however, it really means that it has the potential to be elastic. Amazon EC2 will not automatically scale your application as your server becomes heavily loaded. It is still up to the developer to manage that scalability problem.

So who's tackling this problem? Many startups have recognized the need for management early on and have built management capabilities on top of the existing cloud infrastructure/platforms. RightScale is one of the early pioneers in this space. Their solution solves many of the management issues such as auto-scaling and load balancing.

Monitoring

Monitoring, whether is for performance or availability, is critical to any IT shop. We are not talking about just how much CPU or memory the machines are using. We are talking about performance of transactions and disk IO and others. CPU and memory usage are misleading most of the time in virtual environments. The only real measurement is how long your transactions are taking and how much latency there are. According to High Availability's article on latency:

Amazon found every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%. A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition.

So who's tackling this problem? Hypernic's CloudStatus is one of the first to recognize this issue and developed a solution for it. They started with monitoring of Amazon's web services, then recently added monitoring for Google App Engine. In addition, RightScale's solution can also provide monitoring for the virtual machines under their management.

Reliability and Availability

I won't beat the dead "Gmail down, EC2 down, etc down" horse here. But the truth of the matter is enterprises today cannot reasonably rely on the cloud infrastructures/platforms to run their business. There’s almost no SLAs provided by the cloud providers today. Even Jeff Barr from Amazon said that AWS only provides SLA for their S3 service. I haven’t researched the SLA issue so not sure how true that is. But if it’s true, I think this will be one of the biggest factor, if not the biggest factor, in enterprise adoption. Can you imagine enterprises signing up cloud computing contracts without SLAs clearly defined? It’s like going to host their business critical infrastructure in a data center that doesn’t have clearly defined SLA.

We all know that SLAs really doesn’t buy you much. In most cases, enterprises get refunded for the amount of time that the network was down. No SLA will cover business loss. However, as one of the CSOs I met said, it’s about risk transfer. As long as there’s a defined SLA on paper, when the network/site goes down, they can go after somebody. If there’s no SLA, it will be the CIO/CSO’s head that’s on the chopping block.

So who's tackling this problem? Well, again, no one is today as far as I know. Maybe some startup will come up with clever idea to provide SLA as a third party vendor (read: cloud insurance.) Or maybe the cloud providers will grow/wake up and actually do something to encourage the enterprise adoption.

Virtualization Security

Security is a huge area that encompasses many different things, including the standard enterprise security policies on access control, activity monitoring, patch management, etc. On top of that, virtualization security is something that most enterprises are just starting to grasp but don't fully understand. Many IT people still believe that the hypervisor and virtual machines are safe. Recent presentations from Blackhat has demonstrate that we shouldn't sleep so tight at night. As IT shops get more educated on the virtualization security issues, it will become one of the factors they will consider when they move into the cloud. Access control and monitoring of the virtual infrastructure will be on top of their mind.

So who's tackling this problem? There are quite a few startups like Reflex, Blue Lane and Catbird that are creating privileged VAs that claim to protect the VAs running on VMware's ESX servers. However, ensure you do your research on the performance of these solutions first before adopting one of them. Other startups (unnamed) are creating interesting solutions in protecting the actual virtual infrastructure themselves, e.g., how do you protect and monitor access to the ESX servers? how do you control and monitor the movement of virtual machines using live migration or VMotion.

---

Cloud computing is here to stay. It will be the next big wave and will be adopted by enterprises. However, the industry as a whole needs to answer some of these challenges and ease the enterprises' concerns.

Posted by on August 23, 2008 in Cloud Computing , Security | Permalink | Comments (0)

Tough Security Questions for SaaS Providers - Part 2

[ Originally posted at OnSaaS ]

This is part 2 of the tough security questions for SaaS providers. In part 1 of the series, we asked the following questions:

1. Data Locality - Where's my data?
2. Data Segregation - How is my data segregated with other customers, potentially my competitors?
3. Data Access - Who can access my data in your company?
4. Access Audit - Who has accessed my data and where's my access logs?

We are continuing this discussion with the following questions in part 2.

5. How are the users authenticated and authorized?
6. Web Application Security - How secure is the SaaS provider's web application?
7. Data Breaches - How do you protect my data from insider breaches?
8. PCI DSS - Are you compliant with PCI DSS?

5. How are the users authenticated and authorized?

Companies have spent hundreds of man years and millions of dollars trying to setup single-sign-on systems inside the corporate firewalls. Most companies, if not all, are storing their employee information in some type of LDAP servers. In the case of SMB companies, a segment that has the highest SaaS adoption rate, Active Directory seems to be the most popular tool for managing users. In many cases, companies have designed their IT infrastructure so that all authentication, including VPN, web proxy, file server, and others will go through this single infrastructure. The process of employee onboarding and termination is much easier this way.

Just as companies start to have some success, the advent of the SaaS model changes the scenario again. With SaaS, the software is hosted outside of the corporate firewall. Many times user credentials are stored in the SaaS providers' databases and not part of the corporate IT infrastructure. This means SaaS customers must remember to remove/disable accounts as employees leave the company and create/enable accounts as come onboard. In essence, having multiple SaaS products will increase IT management overhead.

SaaS customers will start asking questions on identity and access integration and providers would be wise to design such features in early on. For example, SaaS providers can provide delegate the authentication process to the customer's internal LDAP/AD server so that companies can retain control over the management of users.

6. Web Application Security - How secure is the SaaS provider's web application?

One of the "must-have" requirements for a SaaS application is that it has to be used and managed over the web (in a browser.) This creates an interesting scenario. In the on-premise scenario, when a vulnerability is found, at least you have your firewall protecting the application so you may get a bit more time to patch it (assuming the application vendor provides the patch in a timely fashion.) However, in the SaaS world, there is no such luxury. Any vulnerability identified can potentially have detrimental impact on all of the customers. Even leading security companies aren't immune to security holes in their web applications.

Web application security is quite a hot topic these days and it's discussed by many security researchers such as rmogull and RSnake. Here's an interesting article on "What web application security really is".

Verizon Business recently released their Verizon Business 2008 Data Breach Investigations Report. Of all the breaches, 59% of the breaches involve hacking, with the following breakdown:

  • Application/Service layer -39%
  • OS/Platform layer - 23%
  • Exploit known vulnerability -18%
  • Exploit unknown vulnerability - 5%
  • Use of back door -15%

Attacks targeting applications, software, and services were by far the most common technique, representing 39 percent of all hacking activity leading to data compromise. This follows a trend in recent years of attacks moving up the stack. Far from passé, operating system, platform, and server-level attacks accounted for a sizable portion of breaches. Eighteen percent of hacks exploited a specific known vulnerability while 5 percent exploited unknown vulnerabilities for which a patch was not available at the time of the attack. Evidence of re-entry via backdoors, which enable prolonged access to and control of compromised systems, was found in 15 percent of hacking-related breaches. The attractiveness of this to criminals desiring large quantities of information is obvious.

Currently there's really no mandate or requirement for SaaS providers to provide detailed security analysis of the SaaS application. However, it would be wise for the SaaS providers to start considering something similar to what PCI DSS has required of the merchants:

  • 6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
    • 6.5.1 Unvalidated input
    • 6.5.2 Broken access control (for example, malicious use of user IDs)
    • 6.5.3 Broken authentication and session management (use of account credentials and session cookies)
    • 6.5.4 Cross-site scripting (XSS) attacks
    • 6.5.5 Buffer overflows
    • 6.5.6 Injection flaws (for example, structured query language (SQL) injection)
    • 6.5.7 Improper error handling
    • 6.5.8 Insecure storage
    • 6.5.9 Denial of service
    • 6.5.10 Insecure configuration management
  • 6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
    • Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
    • Installing an application layer firewall in front of web-facing applications.

Additional sources of information provided as a starting point for more information on web application security would include


Trey Ford of Security Spin Control has a fairly good explanation of the recently released PCI information supplement on requirement 6.6.

SC Magazine also has an article on Deconstructing PCI 6.6 for the management folks.

7. Data Breaches - How do you protect my data from insider breaches?

In the Verizon Business breach report blog, Verizon Business stated that

While criminals more often came from external sources, and insider attacks result in the greatest losses, criminals at, or via partner connections actually represent the greatest risk. This is due to our risk equation: Threat X Impact = Risk
  • External criminals pose the greatest threat (73%), but achieve the least impact (30,000 compromised records), resulting in a Psuedo Risk Score of 21,900
  • Insiders pose the least threat (18%), and achieve the greatest impact (375,000 compromised records), resulting in a Pseudo Risk Score of 67,500
  • Partners are middle in both (73 39% and 187,500), resulting in a Pseudo Risk Score of 73,125

Many SaaS advocates claim that SaaS providers can do a better job at protecting the customers' data. Unfortunately, just because the data is now in the cloud, it does not reduce the risk of insider breaches. Insiders still have access to the data, they are just accessing it a different way. Just because the data is in the cloud, the responsibility of segregation of duties and access authorization still fall on the customers, not the SaaS or cloud computing providers. So yes, it may reduce the chance of insiders getting direct access to, say, a database, it does not in any way reduce the risk of insider breaches. In fact, it may even increase the possibility as you now have to take into consideration of the cloud or SaaS providers’ employees. They have access to a lot more information and a single incident could expose information from many customers.

SaaS providers should be prepared to answer questions on what tools and processes are utilized to ensure segregation of duties and protect from insider breaches. Remember, in the case of the mult-billion dollar insider incident at Société Générale, IT management had implemented all of the controls recommended by auditors, but nobody was monitoring them. So it's extremely critical to be able to show the processes around these security controls.

8. PCI DSS - Are you compliant with PCI DSS?

PCI DSS has a specific section for hosting providers (including SaaS providers):

Requirement A.1: Hosting providers protect cardholder data environment

As referenced in Requirement 12.8, all service providers with access to cardholder data (including hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.4 states that hosting providers must protect each entity’s hosted environment and data. Therefore, hosting providers must give special consideration to the following:

A.1 Protect each entity’s (that is merchant, service provider, or other entity) hosted environment and data, as in A.1.1 through A.1.4:


  • A.1.1 Ensure that each entity only has access to own cardholder data environment
  • A.1.2 Restrict each entity’s access and privileges to own cardholder data environment only
  • A.1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10
  • A.1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider.

A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS. Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not necessarily guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.

Simply put, SaaS providers must be compliant with PCI DSS in order to host merchants that must comply with PCI DSS.

We will continue with our tough security questions in part 3 of this series.

Posted by on July 07, 2008 in Cloud Computing , Compliance , SaaS , Security | Permalink | Comments (0)

Tough security questions for SaaS providers - Part 1

[ Originally posted at OnSaaS ]

We will be writing a series of blog posts on the tough questions that SaaS providers can expect to get from customers or they should ask themselves. The questions will span many different areas including security, compliance, sales, marketing and operations. This is Part 1 of the security questions.

As we mentioned previously here, one of the biggest obstacle to enterprise SaaS adoption is the issue of trust. Customers are asking SaaS providers "Can I Trust You?!" The security analysts and warriors are asking similar questions.

Some SaaS advocates have argued that concerns for SaaS security are just red herring. It is true that, to date, there hasn't been any major breaches amongst SaaS providers. However, we have already seen some activities such as the breach at Salesforce.com. In addition, we have seen many anecdote evidence that multi-tenant architectures in the B2C (e.g., Flickr, YouTube) world are prone to data leakage.

One may argue that these are consumer sites and are not relevant for the SaaS providers. However, the same technologies and architectures are being used in both the consumer and enterprise world. In fact, as the trend of IT consumerization continues, we will see more and more of the consumer technologies being used in enterprise applications. Think about it this way, what if this Salesforce.com and your customer list popped up in your competitor's screen?

SaaS providers should be prepared to answer security questions from customers and enterprises. Here are a list of questions that SaaS providers will likely get asked during customer trials/evaulations.

1. Data Locality - Where's my data?

Due to compliance and data privacy laws in various countries, locality of data is of utmost importance in many enterprise architecture. For example, in many EU and South America countries, certain types of data cannot leave the country because of potentially sensitive information. In addition to the issue of local laws, there's also the question of whose jurisdiction the data falls under when an investigation occurs. In most cases, the government where the data is housed will likely win. A good example of this type of concern is when the French cabinet banned the use of Blackberry devices.

Many enterprises have architected around these issues for the on-premise software they install. However, with cloud computing and SaaS, this issue is even more exasperated. In a cloud computing environment, sometimes you don't know where your data is stored or where your application is being run; and some proponents of cloud computing are also saying that you shouldn't have to worry about where the computing resources are as long as your application is running and behaving as it should. However, other leaders in the cloud computing space are taking note of the data privacy and locality issues. For example, Amazon recently announced the availability of an European S3 cloud, and Salesforce.com is also planning Singapore data center.  

Given the regulatory compliance and data privacy concerns, SaaS providers should be ready to answer tough questions about where their computing resources are and will customer data be ever transferred outside to another jurisdiction with different laws.

2. ata Segregation - How is my data segregated with other customers, potentially my competitors?

Everyone's talking about the benefits of multi-tenancy in the SaaS world, but many seem to ignore one of the biggest security concerns, mixing customer data together, that came along with multi-tenancy.   

One of the reasons that hampered SaaS adoption initially was trust. End users must trust that the SaaS providers have the best security in place to protect their data and never expose their data to anyone outside of the authorized domain. Therefore, the ability to segregate data by end customer is a critical requirement for the SaaS providers. There are many architectural methods in segregating the end customer data. At the end, the requirements come down to that users must never see the data that they are not authorized to see, and that end customer's data should never be exposed to other end customers. 

Saas Providers would be wise to consider data segregation early on in the architectural design. For most ISVs turning into SaaS providers, this is an unfamiliar territory and should seek guidance if possible. SaaS providers should also understand the customer concerns and address them early on.

3. Data Access - Who can access my data in your company?

Enterprises have spent hundreds of thousands of dollars on identity and access management systems, log management systems and other software to ensure that employees access only information they are allowed. Within the confines of their firewalls, IT organizations may feel that they have the situation somewhat under control. The advent of SaaS have changed that. With the company data outside of the firewall and in a "cloud," IT organizations no longer can control who and when their data-in-the-cloud will be accessed. Without visibility into the cloud, IT organizations are accepting a much bigger risk compare to when everything's inside the firewall. Even though many SaaS providers have offered various capabilities such as authentication integration with customers' own LDAP servers, this perception of lost control is a difficult hurdle to get over.

SaaS providers offering cloud services, whether it's infrastructure, platform or application, should accept the responsibility of protecting customer data as a single breach could affect all of the customers. SaaS providers must be prepared to help customers understand their security policies on user access, activity monitoring as well as segregation of duties.

4. Access Audit - Who has accessed my data and where's my access logs?

The last few years we have seen a rise of log management and SIEM solutions aimed at compliance-aware organizations. These products is responsible for collecting, analyzing, correlating, archiving and reporting on all activities happening inside an IT infrastructure. Part of the reason these products became such a success is because of the need to track and monitor user activities in the world of regulatory compliance. In addition to compliance, IT organizations use logs to help them identify security issues, perform troubleshooting and forensics analysis, and analyze traffic and user patterns.

With software in the cloud, network, system and application logs are no longer easily accessible by IT organizations. They either have to negotiate access to these logs during contract time, or they have find new ways of monitoring user activities. Given that the IT organizations don't "own" the software, it makes it even more difficult to "hack" around the system. Without access logs, IT organizations may not be able to answer simple questions from auditors, such as "who have accessed the financial information in the past quarter?"

Knowing how critical access logs are to compliance, operations and security matters for IT organizations, SaaS providers should consider providing access logs as a part of their normal service or have it as an option for customers. As an example, Amazon's S3 service offers options to enable and download access logs.

We will continue with our tough security questions in part 2 of this series.

Posted by on July 07, 2008 in Cloud Computing , Compliance , SaaS , Security | Permalink | Comments (0)

Visit loglogic.com

I ♥ Logs

Subscribe to this blog’s feed RSS

January 2010
Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Categories
Archives
Blogroll
Blogroll
Compliance
Good Reading
LogLogic
LogLogic Partners
Sites We Watch