Tag Archives: title

[ISN] Cloud security roadmap essential for healthcare as off-site threats persist, experts say

www.healthcareitnews.com/news/cloud-security-roadmap-essential-healthcare-site-threats-persist-experts-say By Jack McCarthy Health IT News January 28, 2016 The onset of cloud computing brought with it an information technology revolution, allowing organizations to have their IT resources hosted off site, reducing their costs and simplifying operations. Unfortunately, the move to the cloud did not mean organizations could forget about requirements for a successful security profile. Healthcare organizations making the move to a cloud-centric strategy can’t lower their guard on security defenses, said Chris Bowen, founder and chief privacy and security officer of ClearDATA, a healthcare cloud computing company. “People may think that by offloading security responsibility to the cloud, they won’t have to worry, but that’s not the case,” Bowen said. “We know that threats exist in the cloud.” Bowen will discuss this issue at HIMSS16 along with J. Gary Seay, senior vice president and CIO of Community Health Systems, Bowen will give a presentation entitled, “Developing a Cloud Security Roadmap.” […]




Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] How much at risk is the U.S.’s critical infrastructure? (fwd)

www.csoonline.com/article/3024873/security/how-much-at-risk-is-the-uss-critical-infrastructure.html By Taylor Armerding CSO Jan 21, 2016 There is universal agreement that modern warfare or crime fighting is not just about bullets, bombs and missiles in physical space. It’s also about hacking in cyber space. But over the past decade there has been much less agreement over how much of a threat hackers are. On one side are those – some of them top government officials – who have warned that a cyber attack on the nation’s critical infrastructure could be catastrophic, amounting to a “cyber Pearl Harbor.” Those warnings prompted the recent book by retired ABC TV “Nightline” anchor Ted Koppel titled, “Lights Out: A Cyberattack, A Nation Unprepared, Surviving the Aftermath.” Other experts argue just as forcefully that while the threats are real and should be taken seriously, the risks are not even close to catastrophic. They say those who predict catastrophe are peddling FUD – fear, uncertainty and doubt. […]


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] Call for Papers – YSTS X – Information Security Conference, Brazil

Forwarded from: Luiz Eduardo Hello ISN readers and sorry for the possible cross-postings you might see, on behalf of the conference’s organization team I would like to let you know that YSTS X’s CFP is currently opened. Call for Papers – YSTS X – Information Security Conference, Brazil YSTS 10th Edition Where: Sao Paulo, Brazil When: June 13th, 2016 Call for Papers Opens: December 13th, 2015 Call for Papers Close: March 1st, 2016 www.ysts.org @ystscon INTRODUCTION This is the celebratory 10th edition of the well-known information security conference “you Sh0t the Sheriff” and we are sending this CFP out so you share with us the coolest stuff you’ve been working on. The conference will be happening on June, 13th in a secret location within the city of Sao Paulo, Brazil. This is a great opportunity for you to speak about the latest research you have been working on to the most influential crowd in the Brazilian Information Security realm. ABOUT THE CONFERENCE you Sh0t the Sheriff is a very unique, one-day, event dedicated to bringing cutting edge talks to the top-notch professionals of the Braziiian Information Security Community. The conference’s main goal is to bring the attendees to the current state of the information security world by bringing the most relevant topics from different Infosec segments of the market and providing an environment that is ideal for both networking and idea sharing. YSTS is a an exclusive, mostly invite-only security con. Getting a talk accepted, will, not only get you to the event, but after you successfully present your talk, you will receive a challenge-coin that guarantees your entry to YSTS for as long as the conference exists. Due to the great success of the previous years’ editions, yes, we’re keeping the good old usual format: * YSTS 10 will be held at an almost secret location only announced to whom it may concern a couple of weeks before the con * the venue will be, most likely, a very cool club or a bar (seriously, look at the pictures) * appropriate environment to network with great security folks from Brazil and abroad * since it is a one-day con with tons of talks and activities, we make sure we fill everyone with coffee, food and booze CONFERENCE FORMAT Anything Information Security related is interesting for the conference, which will help us create a cool and diverse line-up. We strictly *do not* accept commercial/ product-related pitches. Keep in mind though, this is a one-day conference, we receive a lot of submissions, so your unique research with cool demos and any other possible twist you can throw in to keep the audience engaged will surely stand out to the other papers. Just in case you need some ideas, some of the topics in security that could be interesting to us: * Mobile Devices & BY0D – Bring your 0wn3d Device * Real Social Networking Threats * Embedded Systems * Everything in Offensive Security * “the” Cloud * Inside Jobs Detection/ Techniques * Big Data * Small Data * Tiny Data (the type that breaks big things) * Internet of all the things you can break * Career & Management topics * (cool and useful) Information Security Policies * Privacy in the Digital World * Messing with Network Protocols * RF Stuff * Mobile Payments * Authentication * Incident Response Stories and Policies * Information Warfare * Malware/ Botnets * DDoS Evolution or Stories (or solution, if you have one) * Secure Programming * Hacker Culture * Application Security * Virtualization * DataBase Security * Cryptography * System Weaknesses * Infrastructure and Critical Systems * Reverse Engineering * Social Reverse Engineering * Reversing Social Engineering * Caipirinha and Feijoada Hacks * and everything else information security related that our attendees would enjoy, the coolest/ different/ most creative submissions win, keep that in mind! We do like shorter talks, so please submit your talks and remember they must be 30 minutes long. (yes, we do strictly enforce that) We are also opened to some 15-minute talks, some of the smart people around might not need 30 minutes to deliver a message, or it might be a project that has been just kicked-off. 15 minutes might be your thing and that’s nothing to be ashamed about. you Sh0t the Sheriff is the perfect conference to release your new projects, other people have released very cool research before they presented it at the bigger cons later in the year. We also like that, a lot. And yes, we do prefer new hot-topics. “First-time” speakers are more than welcome. If you’ve got good content to present, that’s all that matters. SPEAKER PRIVILEGES (and yeah, that applies only to the 30 minute-long talks) * USD 1,000.00 to help covering travel expenses for international speakers * or R$ 1,200.00 to help covering travel expenses for Brazilian speakers who live outside of Sao Paulo * Breakfast, lunch and dinner during conference * Pre-and-post-conference official party (and the unofficial ones as well) * Auditing products in traditional Brazilian barbecue restaurants * Life-time free admission for all future YSTS conferences CFP IMPORTANT INFO (aka: RTFM) Each paper submission must include the following information * in text format only * * Abstract/ Presentation Title * Your Name, company/title, address, email and phone/contact number * Short biography * Summary or abstract for your presentation * Other publications or conferences where this material has been or will be published/submitted. * Speaking experience * Do you need or have a visa to come to Brasil? * is it a 30 minute or a 15 minute talk? * Technical requirements (others than LCD Projector) VERY IMPORTANT DATES Conference Date: June 13th, 2016 Final CFP Submission – March 1st, 2016 Final Notification of Acceptance – April 1st, 2016 Final Material Submission for accepted presentations – May 1st, 2016 (we might ask you to remotely present your talk to us at this date) All submissions must be sent via email, in text format only to: cfp/at/ysts.org IMPORTANT CONTACT INFORMATION Paper Submissions: cfp/at/ysts.org General Inquiries: b0ard/at/ysts.org Sponsorship Inquiries: sponsors/at/ysts.org OTHER STUFF Conference website www.ysts.org Video clips http://youtu.be/6ZblAdYZUGU http://youtu.be/ah-dLkwiK0Y tinyurl.com/ystsendorsements Some Pix tinyurl.com/ysts9pix tinyurl.com/ysts8pix tinyurl.com/ysts7pix1 tinnyurl.com/ysts5pix1 tinyurl.com/yoush0tthesheriff6 twitter @ystscon official twitter hashtag #ystscon We hope to see you there! Luiz Eduardo & Nelson Murilo & Willian Caprino


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] Breaking 512-bit RSA with Amazon EC2 is a cinch. So why all the weak keys?

arstechnica.com/security/2015/10/breaking-512-bit-rsa-with-amazon-ec2-is-a-cinch-so-why-all-the-weak-keys/ By Dan Goodin Ars Technica Oct 20, 2015 The cost and time required to break 512-bit RSA encryption keys has plummeted to an all-time low of just $75 and four hours using a recently published recipe that even computing novices can follow. But despite the ease and low cost, reliance on the weak keys to secure e-mails, secure-shell transactions, and other sensitive communications remains alarmingly high. The technique, which uses Amazon’s EC2 cloud computing service, is described in a paper published last week titled Factoring as a Service. It’s the latest in a 16-year progression of attacks that have grown ever faster and cheaper. When 512-bit RSA keys were first factored in 1999, it took a supercomputer and hundreds of other computers seven months to carry out. Thanks to the edicts of Moore’s Law—which holds that computing power doubles every 18 months or so—the factorization attack required just seven hours and $100 in March, when “FREAK,” a then newly disclosed attack on HTTPS-protected websites with 512-bit keys, came to light. In the seven months since FREAK’s debut, websites have largely jettisoned the 1990s era cipher suite that made them susceptible to the factorization attack. And that was a good thing since the factorization attack made it easy to obtain the secret key needed to cryptographically impersonate the webserver or to decipher encrypted traffic passing between the server and end users. But e-mail servers, by contrast, remain woefully less protected. According to the authors of last week’s paper, the RSA_EXPORT cipher suite is used by an estimated 30.8 percent of e-mail services using the SMTP protocol, 13 percent of POP3S servers. and 12.6 percent of IMAP-based e-mail services. […]


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] Hackfest 2015: Call For Papers!

Hackfest 2015, November 6-7th Quebec City, Canada http://www.hackfest.ca/en/cfp ANSWER THE CALL FOR PAPERS Hackfest.ca is the largest IT security event in eastern Canada and a bilingual event (French and English, even if you only speak English, Hackfest is the perfect place for you, 99% of our attendees speaks it too!) where a social and friendly crowd of over 600 people gathers every year. We welcome each year local and international speakers in Quebec City, Canada, for 2 extraordinary days. What makes it so unique?  The wide range of topics, our unique speakers and also our awesome participants and the ease of discussion with them. Among the participants, we find young professionals, students, hobbyists and influencers/managers of public and private sectors of the province and the surroundings. Hackfest.ca is ideal to: – Share your ideas and expertise in technical defense and hacking with IT professionals – Present a personal or academic research – Introduce us to new defense or hacking tools or techniques you master To answer the CFP please follow up these instruction: Send an email to: conferences@hackfest.ca with the following information: – Your First and Last names – Your email and contact informations (twitter, linkedin, etc.) – Your conference title/subject – Your bio and photo – Abstract of your conference (Max 250 words) – Conference type: 50 minutes (normal), 20 (speed), workshop (60 to 180 minutes) – Why would like to present your conference at Hackfest.ca ? – Requirements: besides the following: power, projector with VGA input and internet connectivity


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] Oracle yanks blog post critical of security vendors, customers

http://www.computerworld.com/article/2969378/security/oracle-yanks-blog-post-critical-of-security-vendors-customers.html By Joab Jackson IDG News Service Aug 11, 2015 Oracle published, then quickly deleted, a blog post criticizing third-party security consultants and the enterprise customers who use them. Authored by Oracle chief security officer Mary Ann Davidson, the post sharply admonished enterprise customers for reverse engineering, or hiring consultants to reverse engineer, the company’s proprietary software, with the aim of finding as of yet unfixed security vulnerabilities. The missive, entitled “No, You Really Can’t,” was issued Monday on Davidson’s corporate blog, then pulled a few hours later. The Internet Archive captured a copy of the post. “We removed the post as it does not reflect our beliefs or our relationship with our customers,” wrote Edward Screven, Oracle executive vice president and chief corporate architect, in a statement emailed Tuesday. […]


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] No, You Really Can’t

https://blogs.oracle.com/maryanndavidson/entry/no_you_really_can_t Mary Ann Davidson Blog By User701213-Oracle Aug 10, 2015 I have been doing a lot of writing recently. Some of my writing has been with my sister, with whom I write murder mysteries using the nom-de-plume Maddi Davidson. Recently, we’ve been working on short stories, developing a lot of fun new ideas for dispatching people (literarily speaking, though I think about practical applications occasionally when someone tailgates me). Writing mysteries is a lot more fun than the other type of writing I’ve been doing. Recently, I have seen a large-ish uptick in customers reverse engineering our code to attempt to find security vulnerabilities in it. This is why I’ve been writing a lot of letters to customers that start with “hi, howzit, aloha” but end with “please comply with your license agreement and stop reverse engineering our code, already.” I can understand that in a world where it seems almost every day someone else had a data breach and lost umpteen gazillion records to unnamed intruders who may have been working at the behest of a hostile nation-state, people want to go the extra mile to secure their systems. That said, you would think that before gearing up to run that extra mile, customers would already have ensured they’ve identified their critical systems, encrypted sensitive data, applied all relevant patches, be on a supported product release, use tools to ensure configurations are locked down – in short, the usual security hygiene – before they attempt to find zero day vulnerabilities in the products they are using. And in fact, there are a lot of data breaches that would be prevented by doing all that stuff, as unsexy as it is, instead of hyperventilating that the Big Bad Advanced Persistent Threat using a zero-day is out to get me! Whether you are running your own IT show or a cloud provider is running it for you, there are a host of good security practices that are well worth doing. Even if you want to have reasonable certainty that suppliers take reasonable care in how they build their products – and there is so much more to assurance than running a scanning tool – there are a lot of things a customer can do like, gosh, actually talking to suppliers about their assurance programs or checking certifications for products for which there are Good Housekeeping seals for (or “good code” seals) like Common Criteria certifications or FIPS-140 certifications. Most vendors – at least, most of the large-ish ones I know – have fairly robust assurance programs now (we know this because we all compare notes at conferences). That’s all well and good, is appropriate customer due diligence and stops well short of “hey, I think I will do the vendor’s job for him/her/it and look for problems in source code myself,” even though: A customer can’t analyze the code to see whether there is a control that prevents the attack the scanning tool is screaming about (which is most likely a false positive) A customer can’t produce a patch for the problem – only the vendor can do that A customer is almost certainly violating the license agreement by using a tool that does static analysis (which operates against source code) I should state at the outset that in some cases I think the customers doing reverse engineering are not always aware of what is happening because the actual work is being done by a consultant, who runs a tool that reverse engineers the code, gets a big fat printout, drops it on the customer, who then sends it to us. Now, I should note that we don’t just accept scan reports as “proof that there is a there, there,” in part because whether you are talking static or dynamic analysis, a scan report is not proof of an actual vulnerability. Often, they are not much more than a pile of steaming … FUD. (That is what I planned on saying all along: FUD.) This is why we require customers to log a service request for each alleged issue (not just hand us a report) and provide a proof of concept (which some tools can generate). If we determine as part of our analysis that scan results could only have come from reverse engineering (in at least one case, because the report said, cleverly enough, “static analysis of Oracle XXXXXX”), we send a letter to the sinning customer, and a different letter to the sinning consultant-acting-on-customer’s behalf – reminding them of the terms of the Oracle license agreement that preclude reverse engineering, So Please Stop It Already. (In legalese, of course. The Oracle license agreement has a provision such as: “Customer may not reverse engineer, disassemble, decompile, or otherwise attempt to derive the source code of the Programs…” which we quote in our missive to the customer.) Oh, and we require customers/consultants to destroy the results of such reverse engineering and confirm they have done so. Why am I bringing this up? The main reason is that, when I see a spike in X, I try to get ahead of it. I don’t want more rounds of “you broke the license agreement,” “no, we didn’t,” yes, you did,” “no, we didn’t.” I’d rather spend my time, and my team’s time, working on helping development improve our code than argue with people about where the license agreement lines are. Now is a good time to reiterate that I’m not beating people up over this merely because of the license agreement. More like, “I do not need you to analyze the code since we already do that, it’s our job to do that, we are pretty good at it, we can – unlike a third party or a tool – actually analyze the code to determine what’s happening and at any rate most of these tools have a close to 100% false positive rate so please do not waste our time on reporting little green men in our code.” I am not running away from our responsibilities to customers, merely trying to avoid a painful, annoying, and mutually-time wasting exercise. For this reason, I want to explain what Oracle’s purpose is in enforcing our license agreement (as it pertains to reverse engineering) and, in a reasonably precise yet hand-wavy way, explain “where the line is you can’t cross or you will get a strongly-worded letter from us.” Caveat: I am not a lawyer, even if I can use words like stare decisis in random conversations. (Except with my dog, because he only understands Hawaiian, not Latin.) Ergo, when in doubt, refer to your Oracle license agreement, which trumps anything I say herein! With that in mind, a few FAQ-ish explanations: Q. What is reverse engineering? A. Generally, our code is shipped in compiled (executable) form (yes, I know that some code is interpreted). Customers get code that runs, not the code “as written.” That is for multiple reasons such as users generally only need to run code, not understand how it all gets put together, and the fact that our source code is highly valuable intellectual property (which is why we have a lot of restrictions on who accesses it and protections around it). The Oracle license agreement limits what you can do with the as-shipped code and that limitation includes the fact that you aren’t allowed to de-compile, dis-assemble, de-obfuscate or otherwise try to get source code back from executable code. There are a few caveats around that prohibition but there isn’t an “out” for “unless you are looking for security vulnerabilities in which case, no problem-o, mon!” If you are trying to get the code in a different form from the way we shipped it to you – as in, the way we wrote it before we did something to it to get it in the form you are executing, you are probably reverse engineering. Don’t. Just – don’t. Q. What is Oracle’s policy in regards to the submission of security vulnerabilities (found by tools or not)? A. We require customers to open a service request (one per vulnerability) and provide a test case to verify that the alleged vulnerability is exploitable. The purpose of this policy is to try to weed out the very large number of inaccurate findings by security tools (false positives). Q. Why are you going after consultants the customer hired? The consultant didn’t sign the license agreement! A. The customer signed the Oracle license agreement, and the consultant hired by the customer is thus bound by the customer’s signed license agreement. Otherwise everyone would hire a consultant to say (legal terms follow) “Nanny, nanny boo boo, big bad consultant can do X even if the customer can’t!” Q. What does Oracle do if there is an actual security vulnerability? A. I almost hate to answer this question because I want to reiterate that customers Should Not and Must Not reverse engineer our code. However, if there is an actual security vulnerability, we will fix it. We may not like how it was found but we aren’t going to ignore a real problem – that would be a disservice to our customers. We will, however, fix it to protect all our customers, meaning everybody will get the fix at the same time. However, we will not give a customer reporting such an issue (that they found through reverse engineering) a special (one-off) patch for the problem. We will also not provide credit in any advisories we might issue. You can’t really expect us to say “thank you for breaking the license agreement.” Q. But the tools that decompile products are getting better and easier to use, so reverse engineering will be OK in the future, right? A. Ah, no. The point of our prohibition against reverse engineering is intellectual property protection, not “how can we cleverly prevent customers from finding security vulnerabilities – bwahahahaha – so we never have to fix them – bwahahahaha.” Customers are welcome to use tools that operate on executable code but that do not reverse engineer code. To that point, customers using a third party tool or service offering would be well-served by asking questions of the tool (or tool service) provider as to a) how their tool works and b) whether they perform reverse engineering to “do what they do.” An ounce of discussion is worth a pound of “no we didn’t,” “yes you did,” “didn’t,” “did” arguments. * Q. “But I hired a really cool code consultant/third party code scanner/whatever. Why won’t mean old Oracle accept my scan results and analyze all 400 pages of the scan report?” A. Hoo-boy. I think I have repeated this so much it should be a song chorus in a really annoying hip hop piece but here goes: Oracle runs static analysis tools ourselves (heck, we make them), many of these goldurn tools are ridiculously inaccurate (sometimes the false positive rate is 100% or close to it), running a tool is nothing, the ability to analyze results is everything, and so on and so forth. We put the burden on customers or their consultants to prove there is a There, There because otherwise, we waste a boatload of time analyzing – nothing** – when we could be spending those resources, say, fixing actual security vulnerabilities. Q. But one of the issues I found was an actual security vulnerability so that justifies reverse engineering, right? A. Sigh. At the risk of being repetitive, no, it doesn’t, just like you can’t break into a house because someone left a window or door unlocked. I’d like to tell you that we run every tool ever developed against every line of code we ever wrote, but that’s not true. We do require development teams (on premises, cloud and internal development organizations) to use security vulnerability-finding tools, we’ve had a significant uptick in tools usage over the last few years (our metrics show this) and we do track tools usage as part of Oracle Software Security Assurance program. We beat up – I mean, “require” – development teams to use tools because it is very much in our interests (and customers’ interests) to find and fix problems earlier rather than later. That said, no tool finds everything. No two tools find everything. We don’t claim to find everything. That fact still doesn’t justify a customer reverse engineering our code to attempt to find vulnerabilities, especially when the key to whether a suspected vulnerability is an actual vulnerability is the capability to analyze the actual source code, which – frankly – hardly any third party will be able to do, another reason not to accept random scan reports that resulted from reverse engineering at face value, as if we needed one. Q. Hey, I’ve got an idea, why not do a bug bounty? Pay third parties to find this stuff! A. Bug bounties are the new boy band (nicely alliterative, no?) Many companies are screaming, fainting, and throwing underwear at security researchers**** to find problems in their code and insisting that This Is The Way, Walk In It: if you are not doing bug bounties, your code isn’t secure. Ah, well, we find 87% of security vulnerabilities ourselves, security researchers find about 3% and the rest are found by customers. (Small digression: I was busting my buttons today when I found out that a well-known security researcher in a particular area of technology reported a bunch of alleged security issues to us except – we had already found all of them and we were already working on or had fixes. Woo hoo!) I am not dissing bug bounties, just noting that on a strictly economic basis, why would I throw a lot of money at 3% of the problem (and without learning lessons from what you find, it really is “whack a code mole”) when I could spend that money on better prevention like, oh, hiring another employee to do ethical hacking, who could develop a really good tool we use to automate finding certain types of issues, and so on. This is one of those “full immersion baptism” or “sprinkle water over the forehead” issues – we will allow for different religious traditions and do it OUR way – and others can do it THEIR way. Pax vobiscum. Q. If you don’t let customers reverse engineer code, they won’t buy anything else from you. A. I actually heard this from a customer. It was ironic because in order for them to buy more products from us (or use a cloud service offering), they’d have to sign – a license agreement! With the same terms that the customer had already admitted violating. “Honey, if you won’t let me cheat on you again, our marriage is through.” “Ah, er, you already violated the ‘forsaking all others’ part of the marriage vow so I think the marriage is already over.” The better discussion to have with a customer —and I always offer this — is for us to explain what we do to build assurance into our products, including how we use vulnerability finding tools. I want customers to have confidence in our products and services, not just drop a letter on them. Q. Surely the bad guys and some nations do reverse engineer Oracle’s code and don’t care about your licensing agreement, so why would you try to restrict the behavior of customers with good motives? A. Oracle’s license agreement exists to protect our intellectual property. “Good motives” – and given the errata of third party attempts to scan code the quotation marks are quite apropos – are not an acceptable excuse for violating an agreement willingly entered into. Any more than “but everybody else is cheating on his or her spouse” is an acceptable excuse for violating “forsaking all others” if you said it in front of witnesses. At this point, I think I am beating a dead – or should I say, decompiled – horse. We ask that customers not reverse engineer our code to find suspected security issues: we have source code, we run tools against the source code (as well as against executable code), it’s actually our job to do that, we don’t need or want a customer or random third party to reverse engineer our code to find security vulnerabilities. And last, but really first, the Oracle license agreement prohibits it. Please don’t go there. * I suspect at least part of the anger of customers in these back-and-forth discussions is because the customer had already paid a security consultant to do the work. They are angry with us for having been sold a bill of goods by their consultant (where the consultant broke the license agreement). ** The only analogy I can come up with is – my bookshelf. Someone convinced that I had a prurient interest in pornography could look at the titles on my bookshelf, conclude they are salacious, and demand an explanation from me as to why I have a collection of steamy books. For example (these are all real titles on my shelf): Thunder Below! (“whoo boy, must be hot stuff!”) Naked Economics (“nude Keynesians!”)*** Inferno (“even hotter stuff!”) At Dawn We Slept (“you must be exhausted from your, ah, nighttime activities…”) My response is that I don’t have to explain my book tastes or respond to baseless FUD. (If anybody is interested, the actual book subjects are, in order, 1) the exploits of WWII submarine skipper and Congressional Medal of Honor recipient CAPT Eugene Fluckey, USN 2) a book on economics 3) a book about the European theater in WWII and 4) the definitive work concerning the attack on Pearl Harbor. ) *** Absolutely not, I loathe Keynes. There are more extant dodos than actual Keynesian multipliers. Although “dodos” and “true believers in Keynesian multipliers” are interchangeable terms as far as I am concerned. **** I might be exaggerating here. But maybe not.


Facebooktwittergoogle_plusredditpinterestlinkedinmail

[ISN] Smartwatches a new frontier for cyber attack, HP study shows

http://www.computerweekly.com/news/4500250398/Smartwatches-a-new-frontier-for-cyber-attack-HP-study-shows By Warwick Ashford Security Editor ComputerWeekly.com 23 Jul 2015 Smartwatches with network and communication functionality represent a new and open frontier for cyber attack, according to a study by HP Fortify. The study revealed that 100% of the tested smartwatches contained significant vulnerabilities, including insufficient authentication, lack of encryption and privacy concerns. The study report entitled Internet of things security study: Smartwatches makes recommendations for secure smartwatch development and use in home and work environments. As the internet of things (IoT) market advances and smartwatches become more mainstream, they will increasingly store more sensitive information, such as health data, the report said. […]


Facebooktwittergoogle_plusredditpinterestlinkedinmail