Question:
Do I need VPNs in the cloud?
Answer:
There are several questions regarding the necessity of VPNs in the cloud.
I think the first step is to clear the concept of cloud. Currently the word “cloud” is used interchangeably for TelCo service provider transport clouds (Network Clouds) (e.g.MPLS) and Cloud computing web services that provide resizable compute capacity as a cloud (like Amazon EC2).. We can also define private service providers like SaaS providers, managed service providers MSPs) as cloud/utility providers (like force.com from salesforce.com, webroot SaaS). Here are some articles defining cloud and transport options.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf
http://mediaproducts.gartner.com/reprints/f5networks/vol3/article4/article4.html
When the necessity of VPNs in the clouds are analyzed, it is obvious that encryption is indeed one of the key pillars of modern information security. And VPNs do provide confidentiality and integrity for data at transit. When cloud networks do transport the data they should provide integrity and confidentiality of data. That being said this does not have to be at layer 3 (IPSEC) or layer 6 (SSL). So focusing on an IPSEC client does not help to address the issue. Confidentiality and integrity services can also be provided via applications themselves. When data is critical you may certainly encrypt data at application layer. (e.g. rights management solutions)
Here is the high level satus for VPNs in the cloud
1- TelCo Network Clouds (Service Provider) – This is the most interesting part. TelCos claim that their shared infrastructure and MPLS VPNs are secure. This is questionable (see article below) but the answer depends on the security needed.
If service provider cloud is not trusted enough you always encrypt at another layer (usually with the application).I personally believe that cloud service provider (TelCos) must be subject to heavier inspection when they are transporting almost all of the intersite traffic. Here are some articles discussing the issue
http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Rey-up.pdf
http://www.techworld.com/networking/features/index.cfm?featureid=3360
I also do not understand why TelCos are exempt from security regulations. (PCI is a good example) TelCos (and their admins, applications, helpdesk people, servers, cable guys…) do have access to almost all interoffice data traffic when MPLS type of TelCo backbone is used. And when the MPLS cloud is compromised, all clear text (yes even the tunneled ones) will be compromised. Real encryption is rarely used. TelCos have been promoting themselves as secure service providers while promoting layered tunnels as segmentation, but I believe they must seal these claims with 3rd party certifications and allowing encryption friendly (where keys are held by the data custodians) clouds.
2- Cloud Computing providers: These providers addressed encryption at their inception thanks to their security aware generation. Before encryption there are several other questions. Here is my post on generic cloud computing security issues: http://security.24kasim.org/2009/02/cloud-computing-security.html
3- SaaS providers. SSL looks like the king at these providers. Segregation of customer data, and customer driven/controlled encrpytion for data at rest and data at transit is required. For data at transit, SSL is secure enough when proper authentication/cert management is provided.
I am still following the following basic principles when I evaluate a platform. Regardless of the nature of technology, all platforms (clouds and others) should answer properly to following areas of information security:
1- Authentication
2- Authorization
3- Confidentiality
4- Integrity
5- Non-Repudiation
cheers,
- yinal
Sunday, June 28, 2009
Clouds and the VPN
Posted by yinal at 0 comments
Labels: Cloud Computing, MPLS
Monday, June 1, 2009
PCI Levels and Validation Requirements for Merchants 2009
This topic is always in the air so here are the official numbers for 2009 from PCI Security Standards Council the official governing body on the PCI requirements for merchants:
Facts:
- Payment Brands determine Merchant PCI levels. Payment Brands are Visa, Mastercard, Discover , Amex etc. They do have the last word on this topic
- Transaction volume is determined by Acquirer
- Transaction volume is aggregate number of transactions (chain stores do count if cards are processed centrally)
Amex
Level 1- Over 2.5 Million Amex card transactions/year, or any merchant who is Level 1 according to another Payment Brand
Action: Annual Onsite QSA or Internal Audit signed by Merchant Co, Quarterly ASV scans
Level 2- 50000-2.5Million Amex transactions/year, or any merchant who is Level 2 according to another Payment Brand
Action: EU only annual SAQ, Quarterly ASV scans
Level 3- Less than 50000 AMEX transactions/year
Action Quarterly ASV scans (recommended) , EU only SQA (recommended)
Level 4- N/A
Action: None
Discover
Level 1 - Over 6 Million Discover card transactions/year, anybody who Discover thinks that they level 1 (discretionary) or any merchant who is validated/reported as Level-1 to another Payment Brand
Action: Annual Onsite QSA or Internal Audit signed by Merchant Co, Quarterly ASV scans
Level 2- 1-6 Million Discover transactions/year, or any merchant who is validated/reported as Level-2 to another Payment Brand
Action: Annual SAQ, Quarterly ASV scans
Level 3- 20000-1 Million Discover transactions/year, or any merchant who is validated/reported as Level-3 to another Payment Brand
Action: Annual SAQ, Quarterly ASV
Level 4- Everybody else with Discover card processing
Action: Determined by Acquirer, Annual SAQ, Quarterly ASV recommended
JCB
Level 1 - Over 1 Million JCB card transactions/year or anybody who is compromised
Action: Annual Onsite QSA audit, Quarterly ASV scans
Level 2- Less than 1 Million JCB transactions/year
Action: Annual SAQ, Quarterly ASV scans
Level 3- N/A
Action: none
Level 4- N/A
Action: None
MasterCard
Level 1- Over 6 Million Mastercard card transactions/year, or any merchant who is Level 1 according to another Payment Brand or anybody who is compromised
Action: Annual Onsite QSA or Internal Audit signed by Merchant Co, Quarterly ASV scans
Level 2- 1-6 Million Mastercard transactions/year, or any merchant who is validated/reported as Level-2 to another Payment Brand
Action: Annual SAQ, Quarterly ASV scans
Level 3- 20000-1 Million Mastercard “e-commerce” transactions/year, or any merchant who is validated/reported as Level-3 to another Payment Brand
Action: Annual SAQ, Quarterly ASV
Level 4- All other Mastercard merchants
Action: Compliance validation is at discretion of acquirer: Annual SAQ, Quarterly ASV recommended
Visa Inc
Level 1- Over 6 Million Visa card transactions/year (all transactions not just e-commerce), or any global merchant who is identified as Level 1 by Visa by any Visa Region
Action: Annual Onsite QSA or Internal Audit signed by Merchant Co, Quarterly ASV scans and attestation of compliance form
Level 2- 1 Million to 6 Million Visa card transactions/year (all transactions not just e-commerce),
Action: Annual SAQ, Quarterly ASV scans and attestation of compliance form
Level 3- 20000-1 Million Visa “e-commerce” transactions/year
Action: Action: Annual SAQ (In Canada SAQs require QSA reviews), Quarterly ASV
Level 4- Merchants processing less than 20000 e-commerce transactions/year or merchants processing up to 1M any channel Visa transactions/year
Action: Compliance validation is at discretion of acquirer: Annual SAQ, Quarterly ASV recommended
Visa
Level 1- Over 6 Million Visa card transactions/year (all transactions not just e-commerce), or compromised merchants
Action: Annual Onsite QSA or Internal Audit signed by Merchant Co, Quarterly ASV scans and attestation of compliance form
Level 2- 1 Million to 6 Million Visa card transactions/year (all transactions not just e-commerce),
Action: Annual SAQ, Quarterly ASV scans and attestation of compliance form
Level 3- 1 (one) to 1 Million Visa “e-commerce” transactions/year
Action: Annual SAQ, Quarterly ASV or use PCI DSS certified processor for all transactions
Level 4- Merchants processing up to 1 Million any channel Visa transactions/year
Action: Compliance validation is at discretion of acquirer: Annual SAQ, Quarterly ASV recommended
Of course all parties who process store or transmit credit cards must follow PCI requirements (PCI-DSS) regardless of their levels.
I will cover reporting requirements for merchants in another post.
Posted by yinal at 1 comments
Labels: compliance, PCI
Sunday, April 5, 2009
Securing Legacy Windows Applications
Question:
What are some techniques for securing legacy Windows server applications using virtualization and/or sandboxing?Answer:
……,
I do come across these legacy applications everyday and you are right they are not going away and we have to deal with them.
VMware and the other virtualization solutions will not make legacy windows applications more secure (or less secure) . They will just virtualize legacy host systems and fill the need for multiple hardware hosts. You may certainly choose to segment hosts via virtualization, if you believe that it is easier to apply high end IPS/FW/Content security systems inline. This is technically possible in several ways,
1- Deploying hypervisor behind security controls
2- Deploying virtualized security appliances in between vm images.
Your options are not that much different on non-vm deployments. Legacy windows systems are tough to secure for the following reasons:
1- They are usually deployed on vulnerable operating systems, the patches are not available for the operating systems.
2- Host based security controls are usually not compatible (HIPS, AV, FW, Logging, Identity Management etc)
3- Ancient communication protocols are used (RPC, older network stacks, clear text non authenticated file transfers etc)
4- Don’t have the developers of the apps at reach, it is not easy to patch application vulnerabilities…
And the list goes on for the reasons that you already know.. Here are practical solutions: 1- Deploy file integrity monitors, registry monitors. These MD5/SHA1 based tools are independent of the OS, they bring some security. You need to identify critical files/filesystems yourself.
2- Migrate user management to new systems if possible (this is usually not possible but try – avoid NT4 domains, allow local admin users only). Migrate old databases/database connectors to new ones if possible (applications stays intact /data moves to a new home, technically to a more secure one)
3- Segment these servers, they will be compromised since they cannot be properly secured. Do not keep them in the same segment with other “decently” secured hosts/applications. If possible use 1 new segment per host. Usually it is difficult to change IP settings so you can use transparent firewalls/IPS at Layer2
4- After segmenting , assume that these legacy segments are untrusted, apply the security controls that you apply to untrusted segments.
5- Run vulnerability assessments continuously, and know your vulnerabilities. Run your action plan based on the findings…Pen test if the stakes are higher.
6- You will probably see buffer overflows, monitor uptime and get curious after unplanned reboots ,systems halts
7- Log everything at network level (not on host or at application level). Allow access at need to know level. Restrict access by any means (IP, client etc).. Make sure that you have audit trail.
8- Have a migration plan, if not make sure that your risk statement includes the risks associated with these hosts.
Good luck, cross your fingers,
cheers,
- yinal ozkan
Productivity Metrics
Question:
What do you think are key productivity metrics for an infrastructure operations group? What according to you are key productivity metrics for running an infrastructure operations group.
Answer:
In productivity metrics, my approach is to compare the delta in output for a fixed input. That is why it is slightly different than regular metrics such as plain uptime, or MTTRs.
Quality Principles: Cost, quality and delivery fulfillment.
Fiduciary Principles: Effectiveness and efficiency of operations, reliability of information, regulatory compliance.
Security requirements: Confidentiality, Integrity, and availability
But it is easy to classify in different ways, the idea is to measure productivity metrics instead of raw metrics (build a baseline for an input and start comparing a baseline of metrics and get an idea on the productivity for certain input)
For the key metrics representation I would go with %#$” (percentage, number, dollar and time,)
The outputs at infrastructure operations to build comparative productivity metrics can be (but not limited to):
Per Role Outputs:
# Last year Level 1 Engineer was closing 8 priority-1 tickets a day this year 20
# Last quarter Level III engineers were completing 2 projects/month, this quarter 1
% Percentage of positive feedbacks per role
Time: MTTR/MTBFs baselines
Time: Unplanned downtime baselines
Time: Cycle time provisioning a new infrastructure component was 1 week now it is 3 days
$ Per ticket cost was $100 now it is $20
% Percentage of infrastructure costs charged back to business was 50% now 80%
$ Cost of running my team was $x now $y
$ Unplanned downtime impact in $ terms was $x now $y
% Percentage of planned/on time completed change requests – over time/cost
% Percentage of systems compliant with policy requirements – over time/cost
% Percentage of systems with the required OS/patch levels – over time/cost
It is easy to deploy custom metrics based on your environment as long as you stay with the productivity focus. You can also build your metrics from the frameworks you are following (PCI, FFIEC, COBIT etc)
- yinal ozkan
Posted by yinal at 0 comments
Labels: metrics
Monday, March 23, 2009
Information Security Career Advise
I have a masters in Network security and working as a Information security and network analyst. I also have a CCNA and trying to figure out if i should head the cisco way to get ccsp/ccnp or get into the ISC2 arena. How are Infosec jobs in the North west region? What are the exact skill set companies are expecting for entry,mid level positions in information security and network administration ? Answer: xxxxx, As usual getting them all is the best but we all know that you need to prioritize. I think with a grad degree you have already made a good investment. On the policy/information security/risk side CISSP and CISM best practices certifications do help you to speak the same jargon with the industry. When you get these certs, you will naturally acquire the jargon and you may also become a member of ISSA, ISC2 or ISACA to join the social networks that come with these certifications. I also like the CISA certification where you get an official auditor title. These certifications will play nice with your Masters Degree in Network Security. The member websites also provide plenty of frameworks, tools and methodologies to begin with. Product vendor certifications are different. These certifications usually open the door for entry level positions. For example if you have CCSP, and the position you are applying to is a Cisco shop, you have a higher chance. There is a big gap when you compare vendor certifications with generic security best practice certifications though; vendor certifications are usually very hands on and they do require day to day sharpening of skills- and you cannot do this alone, yourself, away from the vendor, try this path only if - you like operations and hands-on troubleshooting - you have a change to use these products in your daily life - you have a chance to work on complex requirements (for example if you have never worked on a complex dynamic routing environment, your Cisco routing cert is valueless) Once you become a subject matter expert on a vendor product you may command a higher income, but that is not a work from home and then get certification process. - Your main question is about the jobs. In small shops information security and network management are usually merged in 1 group/role... In Again, certifications are just 1 component of the hiring decision matrix; experience, work ethic, income expectations, work authorizations, people skills usually play a larger role in hiring decision, but it is correct that certifications may help you to pass the non-IT recruiter screenings. You should choose the path that makes you happy to work. That will make you successful regardless of the path you choose. If you will enjoy working on security policies at 11pm, if you won’t see the work as “pays the bill” thing, that is the right path for you. If you are ambitious, and you believe you have the bandwidth to get both vendor and best practice certifications just go for them, it is not tough. The trick is that “job market” can drive you only to a certain point, the rest is dependant on your personal interest and you enthusiasm for the path you choose. Let me know if you have a specific question, Regards, - yinal ozkan p.s. you may check my previous posts related with this topic: http://security.24kasim.org/2008/10/it-security-consultant-jr.html http://security.24kasim.org/2007/08/are-cissp-cisa-and-cism-credentials.htmlQuestion:
Saturday, February 28, 2009
Cloud Computing Security
Question: What are your concerns about cloud computing security? I am not concerned. What we expect from any solution provider is no more different than what we expect from a cloud computing service/infrastructure provider. Can they deliver it? Well,, I do not think they (cloud computing providers) are worse than incumbent corporate IT security teams in charge today. At the end of the day , cloud computing is going through a similar security management path that private networks had followed for years (on a different scale :) In the last month, I have seen several posts on several platforms regarding “Cloud Computing Security”. Without getting into the context so many experts delivered whitepapers, articles posts. Here are the concerns in simple English: 1- Who reaches to my data? Any privacy? 2- Where is my data? 3- Can they control outbreaks in a distributed environment? 4- Can I get through compliance? 5- Can I or can my peers audit security? On the western front security requirements are same. Cloud computing does not change the requirements of information security, so to simplify the concept, we may claim that the what we expect from cloud computing provider is no more different than what we expect from corporate IT. Who reaches your data in the cloud? – Well that is a question that you must ask before signing the contract, technically it is not worse than what your TelCo providing MPLS; did you ever wonder who taps your data over the WAN? Make sure that the contract terms are in favor of PII and relevant compliance requirements that you are subject to. And do not be contained with sales material from Cloud Computing provider, audit it, (I actually know ways to bypass queries, so hire a good auditor who can accredit cloud computing provider’s claims – e.g. they can say access to data is subject to need to know, but it is usually not the case) Where is my data? – Your data is factually in the cloud, you cannot know; it can be everywhere, but as long as it is secure, your BCP/DR plans are in place, and you are not breaking the law by sending data overseas you should be fine, why do you care, do you see your money when it is in the bank, you worry because it is not in your home safe? (I think this is a bad allegory for today:) Again, audit the claims, put it in the contract. Can they control the outbreaks? Is it a controlled environment? – I can make a bold claim that the cloud computing services have a higher availability than corporate IT services. They are usually redundant in gigantic terms, and they do hire brilliant engineers in bulk (see the providers, google, microsoft, amazon, salesforce ? ).. Things go wrong everywhere, so make sure that you always have an isolated plan b in the cloud, and again put it in the contract and test it, make sure BCP/DR works Can I get through compliance? - Easily, if it is included in the contract , passing compliance will be easier than ever, my cloud computing provider goes through PCI, HIPAA, SoX, ISO 27001 et al, they pass , I pass, what a wonderful feeling.. Well, if your provider does not offer compliance services, then ask for it, at the end of the day you may not be able to dispatch auditors to 500 data centers (big 4 dream) Can we/peers audit it? – You must, the cloud computing provider must open like an encryption algorithm, remember the old basics security thorugh obscurity is no security at all..Again put it in the contract, do the sampling right (you cannot audit it all, be a pramatist) and audit it. If you have a specific question, I can write the specifics and play the devils advocate, Regards, - yinal ozkan
Posted by yinal at 0 comments
Labels: Cloud Computing, SaaS
Friday, December 26, 2008
Differentiation of Log Management Solutions
Question:
Centralized Log Management
I'm look for an enterprise log management solution, which can collect log of various network devices, servers(primarily windows servers). The purpose of the same is primarily for complaince. eg:- detecting security issues, troubleshooting etc. I have read lot of articles, but haven't found a good document containing technical differentiation of the various Log Management products on offer. I require your professional suggestion on the subject.
Rgds
xxxxxx
Answer:
xxxxxx,
Here is a good start if you are looking for high level documents:
http://www.securitynews.cz/secnews/security.nsf/0/D328A8B95CC377A2C12572EF0069DF63/$file/Gartner_MQ.pdf
http://www.sans.org/score/esa_current.doc
On the technical site I would check the following areas with the solution provider:
1- Compatibility (which products are officially supported as the log source)
2- What are the event aggregation/consolidation/normalization and correlation options
3- What if the log source is not supported? How easy is it to integrate?
4- How is licensing? When the deployment is distributed, and you have remote event collectors how does it work? (per event, per core, per site etc)
5- What are the out of the box reports? (Ask for actual reports, do not just say yes to report names, do not just buy in ISO 27001 or PCI report are ready sales pitch)
6- How do you configure custom reports? Easy?
7- Do you have role-based management? Integration with LDAP, AD et al?
8- How do you integrate with other enterprise tools? Ticketing? GRC? Workflow etc? Easy?
9- Do you baseline data for anomaly detection? Do you support flow data analysis?
10- Can you get the solution in SaaS or fully managed MSSP format?
11- How do you scale?
12- How do you integrate with 3rd party storage solutions?
13- Is it more difficult than Google when you run a search?
14- How many people are required to run the operations? How many people are required to deploy it? Do you have formal training classes?
15- How do you maintain high availability? (Esp when you have multiple levels of agregation
16- Is it possible to store/analyze raw network traffic?
As discussed above and in other previous posts there are several "commercial" solutions to manage log data win servers, network equipment, UNIX servers, security devices etc. Depending on your requirements and event sources, the solutions may vary. I personally work with RSA Envision (formerly Network Intelligence), Cisco MARS, Loglogic, Q1 Labs and eIQ Networks but there are many other solutions. (e.g. IBM, CA, Novell, Arcsight, Intellitactics, NetForensics, TriGeo, Symantec, Quest, Consul, SenSage, and OpenService) In the meantime Nortel, Juniper and Enterasys have Q1 based offerings as well.
If you look at just the logging manager, you can extend solution set with LogRhythm, Splunk, Snare and Kiwi Syslog Daemon.
If you have a specific question let me know,
cheers,
- yinal
Why GRC does not stick?
GRC in IT field is supposed to be next best thing. But why is it not here yet?
The term IT-GRC is not a fabricated name. It is a real world response to an existing requirement which has evolved within the right steps: At the beginning there were only simple logs and policies, then came the tools, methodologies, and integrated solutions under the SIEM name. SIEM wasn’t enough, we needed a solution set for managing governance risk and compliance together, and then we had the IT GRC.
IT-GRC has all the good signs of the next killer solution, but why it is not mainstream? Many people including myself ask the same questions..
I would like to use the analogy in a very popular business book “Made to Stick” by Chip and Dan Heath.
Here is the book’s outline: The acronym "SUCCES" (with the last s omitted) abbreviates the ideas that stick... Each letter refers to a characteristic that can help make an idea "sticky":
Simple — find the core of any idea … First of all GRC has 3 cores (like an odd Intel processor) and each core points at different directions and groups in IT organizations. While we have difficulty in finding the the core of Governance, Risk of Compliance, we need the interpret all 3 cores together. Nobody can claim the presenting the core of GRC idea is simple (with the exception of funny SAP people who think GRC is SoD)
Unexpected — grab people's attention by surprising them. GRC is not surprising. We have been waiting for such a solution for years, there were simply not enough drivers for a commercial one. Within the name of toolkits, methodologies everybody had a hodgepodge workflow; at the end who beats a nice combination of excel, word and lately sharepoint documents :) . An organized solution such as IT-GRC that can tie into the governance of IT processes risk and compliance was always a project in progress. Luckily some vendors delivered much better organized solutions. But at the end of the day it was not surprising.. When I make a presentation on GRC, the first question that I get it (Can I buy a tool that delivers what you telling about?) The question is wrong of course but it steals all the “unexpected beauty of the solutions sets
Concrete — make sure an idea can be grasped and remembered later. No it won’t be remembered easily even if Gartner says so. GRC covers a broad area, and it is not easy to find individuals who carry the responsibility and the attention span for all the GRC solutions.
Credibility — give an idea believability. GRC is too good to be true. Since it is new in the IT field, credibility is not easy. Many of the vendors will oppose to this statement, but it is difficult to give credibility to a toolset where the implementation and the operational details of specific customers carry a higher role. Like ERP deployments, IT GRC deployments have to be unique for every operation. Toolsets require deployment and they need to be supported by management and operation teams. Credibility will eventually show up with the maturity of the solutions. There are some vendors out there with great customer names, which may form a good start.
Emotion — help people see the importance of an idea. The emotion was lost for most of the IT with the departure of the dot-com companies. But it is not difficult to create the emotion where governance can positively change the bottomline of the operations. I think this is a matter of time
Stories — empower people to use an idea through narrative. I can tell stories about the firewalls we built in 1994. GRC needs more stories. IT GRC is new, and our stories are limited, a search on Amazon ends up with SAP Oracle and the business side of old world GRC. IT GRC stories are not fully published yet.
It will stick at some point, but hopefully no too late.
cheers,
- yinal
Posted by yinal at 0 comments
Labels: GRC