missinfogeek.net Report : Visit Site

Technical data of the missinfogeek.net

Geo IP provides you such as latitude, longitude and ISP (Internet Service Provider) etc. informations. Our GeoIP service found where is host missinfogeek.net. Currently, hosted in United Kingdom and its service provider is 34SP.com Limited .

the related websites

bbc.co.uk kemu.ac.ke gov.uk independent.co.uk webcammax.com wck2.companieshouse.gov.uk siemens.com 

HTTP Header Analysis

HTTP Header information is a part of HTTP protocol that a user's browser sends to called Apache containing the details of what the browser wants and will accept back from the web server.

DNS

HtmlToText

press "enter" to skip to content miss info geek information rights, knowledge management and random other musings open menu about miss ig geek articles and interviews bite-sized guides home privacy & cookies staying private on the web twitter sidebar add to the gin fund! search tag cloud analogies compliance consent dc/dp incident-response infosec marketing pecr rant rubbish pr categories admin (1) breaches and incidents (5) consent (1) controller/processor (1) culture (2) gdpr (7) wtf (2) recent posts bad privacy notice bingo! whose decision is it anyway? tea, sex and data nothing to see here… i’m a muse|amused miss info geek posts bad privacy notice bingo! published 2018-05-16 snark attack! having spent many, many hours reviewing privacy notices lately – both for the day job and for my own personal edification – i’m discouraged to report that most of them have a long way to go before they meet the requirements of articles 13 and 14 of the gdpr, let alone provide an engaging and informative privacy experience for the data subject. because i am a nerd who cares passionately about making data protection effective and accessible, but also a sarcastic know-it-all smartarse, i created this bingo scorecard to illustrate the problems with many privacy notices (or “policies” as some degenerates call them) and splattered it across social media. hours of fun. i am not just about the snark however, i am also a geek who would much rather there was no need for my hissy fits of piss-taking and so in that spirit, i shall deconstruct here; why the items on the bingo scorecard are bad things to find in a privacy notice. bad things “we may….” a privacy notice is a communication that needs to convey useful information, not a guessing game. if you say you ‘may’ do something, i’m left in the dark as to whether you’re actually doing it to my data, and when that might be, if so. if you’re going to do something, say you do it. if you’re going to do something but only under particular circumstances, then describe those circumstances. if you’re not going to do it, don’t even mention it. “personally identifiable information” this is not the same thing as personal data, it’s a subcategory of personal data. when i see this in a privacy notice, it immediately says to me that either the organisation is either oblivious to the premise and requirements of eu privacy law, or that they are trying to pull a fast one by doing all kinds of stuff with de-identified personal data that they don’t want me to know about. more about the differences between “pii” and ‘personal data’ here : “eu citizens” you will not find the word “citizens” anywhere in the text of the gdpr. feel free to do a search on the text if you don’t believe me. that’s because data protection rights are human rights, and residency status is not a variable for ascertaining humanity. it’s about data subjects located in the eu, data controllers carrying out activities in the eu or data controllers who are offering goods and services to people located in the eu, or who are monitoring the activity of people located in the eu. people. not just citizens. if a citizen of the eu goes to a third country, they lose the protection of eu law. “by <….>, you consent to this processing” consent must be informed, freely-given, specific and unambiguous. that means the data subject needs to take some kind of positive action to indicate their consent to processing which has been described to them, in circumstances where they have a genuine choice and where the consent for processing is not tied to an unrelated activity. by browsing a website and reading the privacy notice, i consent to……nothing at all. by wearing my socks on my ears, i have nice warm ears and look a bit daft but am still not consenting to anything at all. if i were to provide my email address on a company’s website to enter into a prize draw, i would be consenting to having my email addressed used to select and notify the winner of the prize and that’s all. if the company wants to use my email address to send me marketing then they have to get entirely separate consent from me to do so. more about consent for data processing here : “general data protection regulation s “ just one regulation. a big beast, to be sure – but a singular one. if an organisation can’t even get that right, what are the chances that they’ll be paying proper attention to what it actually says? not great, i reckon. ico logo you’re not allowed to use the ico’s logo without their permission . if a website owner uses the ico’s logo without permission then they are acting unlawfully by breaching copyright. if they are willing to act unlawfully in regard to intellectual property, what makes you think they will be any more ethical or diligent about processing your personal data, eh? at best, they are clueless. at worst, they are being deliberately deceptive. either way, their privacy notice is not to be trusted and neither are they. refers to the dpo as the “data controller” a data protection officer is an individual who performs the functions described in articles 37-39 of the gdpr for an organisation (either in-house or on an outsourced basis). a data controller is the organisation which determines the purpose and means of the processing of personal data. even if the data controller is a sole trader, there would probably be a conflict of interest disqualifying them from being the dpo anyway (there’s one for the dp geeks to gnaw on). if an organisation doesn’t even know the difference between dpo and data controller, then the chances of them knowing enough about data protection obligations and rights to be able to process your personal data fairly and lawfully, are pretty slim. “we keep your personal data as long as necessary” see also; “as long as required by law”. more guessing games. how long is that then? unless it’s something outrageous, unexpected or high-risk; why even bother to tell me about it? what is “necessary” and how do you justify it? oh, and if you’re saying there’s a law that requires you to do something with my personal data, please cite that actual law. making a statement saying “we comply with the law” gets you no brownie points – the whole point of the law is that you have to comply with it. you might as well make sure you say “we don’t chop off annoying people’s heads with axes” too. one loooooong page/doc the harder it is for me to read your privacy information, the more likely it is that i will suspect you’re up to no good and make the effort to scrutinise it. now, that’s just me because i’m a suspicious-minded nitpicking smartarse, but even for people who don’t spend their leisure time examining privacy notices, the point of the whole exercise is – as i mentioned above – to effectively communicate information to people about what’s going on in relation to their personal data. the gdpr even says in recital (39) that “the principle of transparency requires that any information and communication relating to the processing of [..] personal data be easily accessible and easy to understand”. making me scroll through acres of dense small print until my brain turns to mulch, is basically doing the opposite of what the gdpr requires. (nb: if you want to see an absolutely beautiful privacy notice, have a look at this . seriously. it’s the best bit of ux i have ever seen. i am a little bit in love……and probably need to get out more) “from time to time…” this is a phrase which conveys absolutely nothing in the way of useful information. which times would those be? 3 times a year? once a week? under what circumstances? every time i [ example redacted in the interests of good taste and public decency ]? it reeks of ‘we couldn’t be bothered to think about this too hard’….or even ‘we daren’t tell them what’s really going on’. either way – not a good look. a waste of pixels/printer ink. lists purposes separately to legal basis this might keep auditors happy when they review your privacy notices so they can tick the ‘article 13 requirements” boxes, but unless there is a clear narrative for the data subject to follow in relation to their personal data; it’s not actually going to meet the obligations of transparency. i want to know what’s happening with my data, under which circumstances, and why you think that’s allowed. separate lists will not allow me to do that. tell me that you’re going to use my postal address to send me news about your latest offers and that you reckon this is in your legitimate interests. tell me that you have to keep gift aid declarations for 6 years because the tax and finance act (or whatever) says you have to. don’t tell me that there are a number of potential purposes for processing my personal data then make me have to try and figure out which one of the potential legal basis you’ve listed somewhere else is being used to justify the processing activities that you’ve described in yet a third separate list. not transparent. not helpful. “administration purposes” administration is an activity not a purpose. it is not an end unto itself. no-one gets up in the morning and goes “ohhh, my whole reason for living is to administrate!” what is the administration activity and why is it being carried out? perhaps you need to make sure my contact details are up to date so that you can chase me for my membership dues, which are a requirement of my agreement with you. maybe you need to make sure that your event tickets are not sold to more people than the venue can accommodate. obviously, there are some legal obligations your organisation must fulfil. so please tell me about them rather than skulking behind the diaphanous skirts of “administration” “including, but not limited to….” if it’s worth mentioning, it’s worth telling me all of it. examples are helpful but they do not replace the legal obligation to describe the processing, the purposes and the legal basis for the processing. if your organisation doesn’t actually know what you’re going to do with my data then i don’t want you to have it. if you know but you’re worried about telling me, then i really don’t want you to have it! looks and sounds like a contract. privacy information, a privacy notice or privacy policy (if you must) is not a legally-binding agreement. it’s not a deed or a contract. it’s a piece of marketing material that just happens to need to be scrupulously honest as well. a good privacy notice not only has to make you feel ok about how your data is being used (while not obfuscating, concealing or outright lying), it should make you want to read it because it is helpful and engaging! privacy notices written by lawyers hoping to outsmart other lawyers are easy to spot – they’re the ones you’d rather scoop your eyes out with a spoon than spend any time reading (unless – perhaps – you’re that kind of lawyer). and don’t event get me started on the american convention of putting really important stuff in capital letters ostensibly to ‘draw attention to it’ but thereby rendering it utterly incomprehensible to anyone. “military-grade encryption” oh, do piss off. encryption is a tool to mitigate a particular type of risk. it is not always the appropriate tool and like any other tool, is only as good as the implementation and competence of the people using it. you could be using 3des to protect the negotiation for your public key exchange, with your own ca in a bulletproof box, but if your sysadmin’s password is “password” or you’ve mixed up your public and private keys, then you wasted a lot of time and money (rather like buying a rocket launcher then using it to bash your own head in). if you couldn’t make head or tail of that last paragraph, then don’t worry – the people who write “military-grade encryption” into a privacy notice don’t know what any of it means either. “we take data protection very seriously” see previous comment on boasting about not axe-murdering people. in conclusion a privacy notice isn’t there to cover your arse. yes, it’s a legal requirement but the purpose of that is not simply to make you jump through hoops like a peke at crufts. the purpose of the legal requirement to provide privacy information is not to give you something to point to to tick off the ‘transparency’ principle, it is the transparency principle. the data subject has the right to be informed. if all you’ve done is obfuscate, bore, deceive or puzzle them then you have achieved the exact opposite of what gdpr requires and must now go all the way back to the beginning and start redrafting your privacy info. whose decision is it anyway? published 2018-05-14 whose decision is it anyway? controller/processor determinations (a.k.a how a data protection anorak spends their leisure time) update: sorry that the tool is not currently working – my supposedly ‘unlimited’ free zingtree account has expired, and they want £984 a year for me to renew it, which i can’t afford. currently looking for alternatives – if you know of one, hit me up! i’ll post a downloadable text version of the tool very soon. following a lot of pre-gdpr kerfuffle online about data controller/data processor relationships (and the varying degrees to which these are direly misunderstood), i spent a geeky sunday night putting together a decision tree tool which should – hopefully – help people who are getting confused/panicked/deeply weary of the search for answers. it’s not intended to be legal advice, it’s not formal advice from me as a consultant and it’s not guaranteed to be absolutely 100% perfect for every possible scenario. it’s designed for the low-hanging fruit, the straightforward relationships (like standard commercial supply chain) rather than the multi-dimensional nightmare data sharing behemoths one tends to find in the public sector. anyway, here it is. enjoy. if you like it, please tell others where to find it. if you have constructive criticism (that’s not “oh you missed out this incredibly niche complex scenario that would only ever happen every 100 years”) please tell me. the tool here are also some useful links: https://ico.org.uk/media/about-the-ico/consultations/2014789/draft-gdpr-contracts-guidance-v1-for-consultation-september-2017.pdf http://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2010/wp169_en.pdf who’s in control? tea, sex and data published 2018-01-08 tea, sex and data comparing consent for processing personal data with consent for sexual activity. many laws, professional obligations, contracts and standards make reference to “consent” as a basis or requirement for something to be done. as i’ve mentioned before in an earlier post, “consent” is not a tick box or a signature, it is a state of relationship between two (or more) parties. with this in mind, i’m going to write about something we’re almost all enthusiastic about (sexual activity) and something i’m [also] very enthusiastic about (data protection) in the hope that comparing the two will lead to greater understanding of how to manage consent as a legal basis for processing personal data, while keeping your attention for long enough to explain… if you haven’t already seen this , it’s an excellent analogy between sexual activity and cups of tea – almost every point made can also be related to processing of data. the main difference here is that a cup of tea is unlikely to have a lasting and damaging effect, whereas both unwanted sexual contact and unfair/unlawful processing of personal data have the potential to cause serious harm to individuals if they occur.* before i get into the similarities though, there are two ways in which consent for getting sexy and processing data are totally different . 1. you don’t *have* to get consent for data processing (and shouldn’t try to, if consent is not the appropriate legal basis) but you always need to make sure that your sexual activities are with consenting adults only. 2. consent for happy fun time can be implied or inferred (carefully). a long-married couple probably don’t need to have a detailed conversation about whether to take advantage of the kids being out that evening – a speculative look in the direction of the bedroom/kitchen/sofa and a twinkle of the eye in response is probably enough to communicate “shall we?” “yes!” effectively. no such parallel exists with data processing – either you have an unambiguous and specific response to “can we use your data in this way for this purpose” or you don’t have consent. ok, those are the significant differences. so, what are the similarities between consent for sexual activity and consent for data processing? what it’s for: specifically consent is not “one size fits all”, if you consent to a (whether a is a cheeky snog behind the bike sheds, or being profiled on social media in order to be served targeted advertising), that does not mean you have also consented to b (which might be a hand up your shirt – or having your social media data sold to an insurance agency to calculate your risk of having a driving accident). it doesn’t even mean that you have consented to future as (snogs or profiling), especially if those future as might take you by surprise. it certainly doesn’t mean that having consented to a with one party, that anyone else can join in without having to ask permission separately (i’m looking at you, data brokers) whether you have it depends on how you get it: evidence of consent may be a legal requirement in some scenarios, but that evidence itself is not “consent”, just a record that something was asked for and an affirmation provided. obviously, if you have been misled or misinformed as to the activity, not given enough information to make an educated decision or if you don’t really have a choice, then no amount of tickboxes, signatures, “i agree” buttons or recordings will suffice. you have not consented. obtaining consent before/during sexual activity doesn’t usually involve either paper or electronic records, although there are apps which purport to fill that……er…. niche (i’m in complete agreement with girl on the net’s views on these apps , by the way [warning also probably nsfw]). however, asking “would you like me to….” or “how about if we…..” rather than just diving in is the right thing to do and doesn’t have to kill the mood – in fact, that kind of conversation can be quite good fun….. a positive response is an indication of consent. no response, or a negative response is very very unlikely to be consent. if someone is impaired in some way so they can’t a) understand the decision or b) communicate their decision then they cannot consent. back off. obtaining consent for processing of personal data doesn’t necessarily need to involve tickboxes or signatures although as evidence of consent is a legal requirement, those are some mechanisms you might want to consider using. what’s important in both circumstances is that you get consent before you start getting jiggy/processing data. it doesn’t last forever: once you have consent, you can do whatever it is you have obtained agreement to do, for as long as that consent was agreed to last. “yes” can turn to “no” at any time. if you don’t give the other party the freedom to change their mind, then you don’t have valid consent. regret does not retrospectively turn a ‘yes’ into a ‘no’. while many of us may have woken up and thought “oops” when recalling the night before; this does not invalidate any informed, freely-given consent that was provided at the time. the past cannot be undone, only learned from. likewise, if i give an advertising agency permission to use my photo, while i can tell them to stop using it later, i can’t make them recall every copy of the image that they published while my consent was in place. withdrawal or refusal is not an invitation to try to continue: no means no. end of. once someone has withdrawn their consent you must stop doing whatever it was you obtained their agreement to do. pleading, bullying, coercing, forcing – these are violations of consent and could be very serious, both for you and for the person whose preferences you have ignored. emotional blackmail to get sex is a favourite tactic of hormone-crazed teenage boys and has (superficial) parallels with companies that send emails to opted-out addresses offering incentives to resubscribe. teenage boys might not realise that what they are doing is wrong (educate them please, parents!) but companies have no excuse whatsoever. it doesn’t last forever: “yes” now does not mean “yes” to every future occurrence. “but you liked sucking my toes last week” does not mean that person wants to suck your toes right now, or at any time in the future. put your socks back on. similarly, asking an organisation to send you info about a specific event you’re interested in doesn’t mean they can send you messages about any other event they run. it’s important to be clear: keep checking that ‘no objection’ has not turned into “no”. consent must be informed to be valid, so if the other party has forgotten what they agreed to then you may not still have their consent – whether that’s the prospect of getting the silk scarves out, or tracking every location they take their phone to. proportionality is advised: signed agreements are not necessarily appropriate for either sexual activity or data processing (although they are relatively common in relationships that incorporate the exotic end of sexual activities [warning possibly nsfw] where the potential for miscommunication could have serious ramifications). likewise, a signed declaration of consent to data processing is probably overkill for the majority of scenarios and is likely to increase both your administrative overhead and the annoyance you’re going to cause to the people who’s data you’re wanting to process. however, as with exotic sexual activities; if there is potential for a high impact, especially any kind of harm to the individual from your processing then it’s likely that you will need to make your consent evidence more stringent and robust. (note: if the processing is *required* in order to carry out a contract, then you should not be asking for consent in the first place as it cannot be freely-given separately to the contract agreement itself). lastly; don’t be a git: if you’re looking for ways to evade obtaining proper consent in order to exploit someone then you are a bad person. this applies in any context. even if you don’t see what you’re doing as exploitation, fiddling with either someone’s physical or intangible self has real consequences – it should only happen with care, respect and communication. so if you are considering processing someone’s personal data, first check the appropriate legal basis . if that’s consent, then ask them for it – being clear about what you want to do and why. keep a record of their response. check in with them after a while to make sure it’s still ok. don’t be sneaky/deceptive/coercive/vague/ask for more than you actually need. and practice safe sex, mm’kay? *nb: i am *not* equating data misuse with sexual assault in terms of seriousness! lives can be ruined by unfair/unlawful/careless data processing (the construction industry blacklist, exposing vulnerable people to their stalkers, medication errors, inaccurate criminal records, credit rating errors….) – these are all really bad things, but nowhere near the horror of being assaulted. nothing to see here… published 2017-11-06 i read today in infosecurity magazine that the law firm appleby whose tax-sheltering habits are currently splattered all over the news, thanks to a massive leak of internal data; have claimed that a) the attack was apparently a sophisticated professional-grade hack and b) there was no evidence of data having left their systems. i laughed out loud apparently, a team of professional computer forensics geeks have been unable to identify how the data was exfiltrated. fair enough actually; it’s entirely possible that appleby had no access controls or security logging in place (this is very common since such things require time, money, effort and thought to set up, corporate enthusiasm for that sort of thing is usually pretty scarce) and so there was simply no breadcrumb trail to follow. this has led them to conclude that a devilishly clever outside actor was responsible rather than a leak from some git on the inside. *sceptical face* – it’s far more likely that an intrusion would leave traces than an internal misuse of privileged access would. (i guess their insurance covers being hacked but not being stitched up by one’s own workforce #cynicalsmirk) but wait a minute…..no evidence that data was exfiltrated clearly does  not  mean that no data was exfiltrated…… the data has been passed to a variety of media outlets, it has definitely escaped somehow. this is an important point – how often, after a reported data leak/loss/hack/etc have we heard a statement from the organisation affected that they have “no evidence” that any data was exposed, misused or extracted? (rhetorical question; they all say that). the absence of evidence is not evidence of absence and such claims should to be taken to mean only that the organisation has limited information as to what really happened to the data. no-one should take reassurance from an open declaration of cluelessness. the other point; about the sophistication of the tactics used to nab the data is that everyone also claims that every information security breach is a sophisticated attack – even when most of them turn out to be teenagers operating from their bedrooms, or result from an unwittingly obliging senior exec clicking on the wrong link or email attachment. i’m not saying that this particular depth charge wasn’t a high-tech military-grade it ninja attack…..only that such things are awfully rare and largely unnecessary thanks to the laxity of infosec controls in most places. anyway, if i were wealthy enough to make using offshore tax avoidance schemes worthwhile, i would probably demand a full infosec audit report from any law firm i was considering handing my data over to….. i’m a muse|amused published 2017-11-06 inspired by my #gdprubbish rantings, the ever-droll javvad malik has put together a handy video guide for all those newly-minted “gdpr consultants” that have been mushrooming up; on how to make as much from this shiny new market as possible….. (nb: this is parody and satire; anyone who actually does the things described herein has no business working in data protection at all and should gtfo asap) consent or not consent? published 2017-06-27 update: sorry that the tool is not currently working – my supposedly ‘unlimited’ free zingtree account has expired, and they want £984 a year for me to renew it, which i can’t afford. currently looking for alternatives – if you know of one, hit me up! i’ll post a downloadable text version of the tool very soon. following on from some of the ranting i’ve been doing about the current unhealthy obsession with consent for processing, here’s a funky tool that i have created for determining whether consent is the appropriate legal basis for processing under gdpr. at the moment, it only covers article 6 but i’m working on another one that addresses special categories of personal data as well. please let me know what you think about this tool in the comments section! verelox, insider threat and gdpr implications published 2017-06-10 if you haven’t heard about verelox, they are a dutch cloud hosting provider who’ve recently been wiped off the internet (along with all of the customers hosting with them) by what is reported to be an attack by an ex-sysadmin, who has wiped customer data and servers . i’ve been seeing tweets and discussions on tech and infosec forums, some of which have queried whether this circumstance would be a breach under gdpr for which regulatory penalties could be enforced. the answer to whether this incident represents a failure of verelox to meet the requirements of gdpr is going to depend on many details which are not currently available, however as a former infosec professional now turned to privacy; i’d be inclined if asked, to give the standard data protection officer answer: “it depends”. because it does. the gdpr requires that organisations take “appropriate technical and organisational measures” to manage risks to the rights and freedoms of individuals whose data is being processed (article 24.1) and specifically, to protect the confidentiality and integrity of personal data in proportion to the risks to the individual and the capabilities of available technology (article 32.1). in this case, it is very likely that verelox will be a data processor rather than a data controller for any personal data that was stored/hosted/collected on their cloud platform, since they were providing infrastructure only and not making any decisions about how people’s information would be used. however, gdpr does bring in data processor joint liability for data breaches (defined as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed” (article 4.12)) and places explicit obligations on data processors as well as data controllers to “ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services”. (article 82). interestingly, the right to compensation does not specify “natural persons” in regard to compensation as it does to the definition of personal data, which may leave the door open for verelox’s customers to make claims under gdpr rather than contract law to recover some of their losses arising from the incident. i’m not familiar with dutch law, so i’ll leave that in the realms of speculation for the moment. what gdpr does appear to say is that verelox could potentially be jointly liable with their customers for claims for damages from individuals, as a result of this incident. whether they are actually culpable is something that will need careful consideration, and this is where i put my infosec hat back on for a while… does the fact that this happened therefore mean verelox’s measures were not appropriate? well, again the answer is going to be “it depends”. based on the information available in news reports at the moment, this seems to be a rare and extreme case of a malicious insider with a grudge acting independently and outside the law. should the company be held responsible for this? one of the factors to consider will be whether this damage was done while the individual was still an insider (i.e. employed as a systems administrator) or whether it happened later on after they left the role? if the attack was carried out later on there is a possibility that verelox might have dropped the ball, since the individual should have had their access revoked as soon as their employment came to an end, and in such a way that it would be difficult to trigger such a meltdown from the outside. if the attack was carried out post-employment then the “technical and organisational measures” verelox had in place may not have been “appropriate”. questions that should be asked are: was there a standard procedure for revoking leavers’ access in a timely manner, was that procedure followed in this particular case, was there a culture of adherence to security procedures in general? if the answer to any of these questions is “no” then verelox might be in for a difficult time ahead. if the attack was planned and set in motion while the individual was an insider; could/should pre-employment vetting or line management support procedures have identified the possibility? this one is tricky, as any predictive measure of human behaviour is never going to be 100% accurate on an individual level. previous and similar shenanigans carried out by a prospective or current employee could be an indicator of higher risk of future shenanigans occurring, but that really depends on the person and the circumstances. no record of any previous shenanigans may mean; this person has done it before but was never caught, this person has never been in circumstances where this behaviour could be provoked, or simply that this person just wouldn’t do a thing like this in any circumstances. there’s just no way to tell in advance. maybe this guy is a nutter who has a tendency to react destructively when upset – but that doesn’t mean we should be advocating for mandatory psychological examinations of all employees who are to be trusted with privileged access as that would be a grossly disproportionate invasion of privacy (and not necessarily accurate enough to be worth the effort either…) what about disaster recovery and business continuity planning? should these plans have included mitigation for this level of malicious damage by a privileged insider? again, maybe – but it depends. does malicious insider damage happen often enough to justify the expense, protocol and monitoring capability that would be required to prevent and detect this activity while managing both false positives and negatives? while this sort of grudge-attack is always a possibility, it may make better business sense to develop, manage and support employees so that the chances of behaviour like this are reduced, rather than make the default assumption that everyone is a potential vandal/criminal and treat them accordingly. in any case; what organisation really has the resources and support available to maintain standby equipment and datastores in a way which make them easy to fail over to in the event of an attack or disaster but too difficult for an admin with a grudge to take out alongside the live system? hindsight is always 20/20-sharp and there are plenty of armchair experts gleefully pontificating about what they think verelox should have done better or differently. in the current absence of detailed information though; there’s no reason to pay any attention to any of them at the moment. it’s easy to say “well verelox should have done x,y,z; they’re idiots for not doing it” but far harder to balance the management approach for predictable but unlikely risks. paying attention to managing the risks that can be managed, in a proportionate way that doesn’t stop the business operating, is the fine line that infosec teams must walk; often in difficult conditions – mostly unappreciated, frequently facing opposition from people who don’t understand or have different views of the risks and dependencies, probably under-resourced and constantly firefighting seems to be the norm for most operational infosec roles. there are cases where all you can do is as much as you can to put in place quick-recovery plans and buy insurance against the things that you really have no control over (like some loony destroying your business operations out of pique). this may well be one of them. tl;dr version – if verelox can demonstrate that they took reasonable and appropriate precautions to mitigate the risk of the attack, then they are unlikely to be subject to penalties or remedies under gdpr. however, if they can’t demonstrate that their measures were developed and maintained to be appropriate to the risks then they may be subject to regulatory enforcement (unlikely) or civil claims (possible). whether gdpr would be the appropriate instrument for bringing action under is not something i’m qualified to comment on. what the gdpr does – and doesn’t – say about consent published 2017-05-31 meme courtesy of jenny lynn (@jennyl_rm) you may have noticed that the general data protection regulation is rather in the news lately, and quite right too considering there is only a year left to prepare for the most stringent and wide-reaching privacy law the eu has yet seen. unfortunately however, in the rush to jump onto the latest marketing bandwagon, a lot of misleading and inaccurate information posing as “advice” in order to promote products and services is flourishing and appears to be drowning out more measured and expert commentary. having seen a worrying number of articles, advertisements, blog posts and comments all giving the same wrong message about gdpr’s “consent” requirements, i was compelled to provide a layperson’s explanation of what gdpr really says on the subject. so, let me start by saying gdpr does not make consent a mandatory requirement for all processing of personal data. and again, so we’re completely clear – gdpr does not make consent a mandatory requirement for all processing of personal data!!! so what does gdpr say about consent? it says that to be allowed to process (i.e. do anything at all involving a computer or organised manual files) personal data, you must have at least one “legal basis” for doing do. let’s call the list of legal basis “good reasons” for now, to keep the language friendly. the good reasons are: when you have consent to process personal data when there is a contract between you and the individual (“data subject”) or between the individual and someone else which requires you to process their personal data in order to fulfil its terms. this also applies to any processing that is needed in order to prepare or negotiate entering into a contract. example: buying a house when there’s a law or legal obligation (not including a contract) that you can only comply with by processing personal data – example, accident reports for health & safety records when someone’s vital interests are at stake unless personal data is processed (usually only applicable to life-or-death situations – e.g. the emergency services having a list of employee names to identify survivors after a building collapse) in the public interest or when acting under official public authority – such as political parties being allowed to have a copy of the electoral register (providing they don’t take the mickey in their uses of it). when personal data needs to be processed for an activity which is in the “legitimate interests” of the organisation (“data controller”) or the individual. now, just because consent is listed first does not mean that it is the most preferable good reason, the most important or the default option. it is none of those things – in fact, when considering which good reason applies to processing, the other options should be tested first. if you picked consent because it was top of the list and consent was later withdrawn, but you realised there was a legal obligation to continue to process the data, you would be in a pickle – either you’d be in breach of privacy law (continuing to process when consent has been withdrawn) or in breach of the other legal obligation. please note that opting for “legitimate interests” as the good reason is not a way of dodging around the prospect that consent may be withdrawn or refused, as there is a nabsolute [ edit; objection *can* be overridden by the data controller in some circumstances ] right for the individual to object to the processing of their personal data when “legitimate interests” is the good reason for processing. all legitimate interests does is save you the effort of having to obtain and demonstrate specific, informed and freely-given consent before you can have or start using the data. when it comes to special categories of personal data (formerly known as “sensitive personal data”), there is another set of legal basis (we’ll call these damn good reasons) which must also be met for the processing to be allowed. in fact, gdpr says that unless one of these damn good reasons is applicable, then you’re not allowed to process special categories of personal data at all. the damn good reasons are: when you have explicit consent or when employment law, social protection law or social security law says you have to do something that requires the processing of special categories of personal data when the processing is required in someone’s vital interests but the individual is incapable of giving consent when the processing is necessary and carried out by a trade union, philosophical or religious non-profit organisation to administer their membership operations when the individual has already and deliberately made the data public when the processing is necessary to defend legal rights, legal claims or for the justice system to function when the processing is necessary in the public interest (just like in the good reasons list) when the processing is necessary in order to provide health care, treatment and management of health care services when public health may be at risk if the processing isn’t carried out when the processing is necessary for archiving, historical or scientific research, or statistical analysis again, although consent tops the list it does not mean that it should be the first choice of damn good reason. as with the other list, it is wise to consider first whether there are other damn good reasons that apply and only choose consent where there are no alternatives. there is some confusion at the moment about the difference between “consent” (good reasons) and “explicit consent” (damn good reasons), especially as gdpr says that for any consent to be valid, it must be “unambiguous”. i’m going to leave the dissection of that to greater minds than mine (see refs). however, i will say that when in doubt, go for whichever approach gives you the most solid evidence. so that’s what gdpr says about whether and when you need consent. however – another law (the privacy & electronic communications regulations, aka “pecr”) says that you must have explicit prior consent before sending any unsolicited direct marketing by email . this is not the same as the good reason/damn good reason “[explicit] consent for processing” but the separate requirements are often confused. it may be in your organisation’s legitimate interests to collect, store and analyse contact info but if you are emailing unsolicited direct marketing messages you will also need to have obtained consent for email marketing from the recipient. a few words on mechanisms vs outcomes (if you’re still reading, congratulate yourself on your fortitude!) ‘consent’ is an outcome – you and the individual have achieved a defined, mutually-understood, relationship in which you as a data controller can process their personal data for a particular purpose and in a particular way. this outcome needs to be an ongoing state of affairs. if the individual later decides to change the relationship and no longer allow you to process their data then you no longer have consent (and must stop and current or future processing). tickboxes, signatures and “click here” buttons are mechanisms for obtaining consent. however, if the agreement you have obtained using this mechanism is not specific, informed and freely-given then you do not have valid consent under data protection law. transaction logs, screen prints, signed documents and call recordings are evidence for the process of obtaining consent. these are only as good as the outcome that the process supports. if the individual has been misled, or they dispute that the processing you are doing is what they actually agreed to, or the processing purpose + good/damn good reason was not made clear to them, or they have simply changed their mind then you do not have valid consent even if you have evidence that consent was asked/supplied at one point in time. consent is not a fire-and-forget activity, and consent obtained once is not set in stone forever. so in order to be able to get and keep valid consent you need to have good processes for obtaining, maintaining and verifying the outcome, ie. the relationship between you and the individual. this means careful attention to training, customer service and content of privacy notices. so, in summary (well done for getting this far!) gdpr does not say “all processing requires consent”- and anyone who says that it does, clearly does not know what they are talking about. ignore them. gdpr says that sometimes you will need to get consent and when that is the case; it sets out the standards that you must meet. consent for unsolicited electronic marketing as required by pecr is not the same thing as consent for processing of data described in gdpr. i hope that clears it all up. more about consent under gdpr if that is the good reason/damn good reason you need to use: https://www.twobirds.com/~/media/pdfs/gdpr-pdfs/23–guide-to-the-gdpr–consent.pdf?la=en https://www.taylorwessing.com/globaldatahub/article-understanding-consent-under-the-gdpr.html http://privacylawblog.fieldfisher.com/2016/the-ambiguity-of-unambiguous-consent-under-the-gdpr/ https://www.whitecase.com/publications/article/chapter-8-consent-unlocking-eu-general-data-protection-regulation gdprubbish published 2017-05-11 gdprubbish unless you’ve been living under a rock, you’ll have noticed that there are lots of people talking about gdpr – which is a good thing. however, there is lots of nonsense being talked about gdpr – which is a bad thing. my twitter timeline, linkedin feed and email inbox are being deluged with advertising for gdpr compliance “solutions” and services – which is fine as long as the product in question is treated as a tool in the toolbox and not a magic instant-fix-in-a-box spell for instant transformation based on some of the twaddle i’ve seen being talked about gdpr lately, and my own experience in supporting data protection within organisations, here is a list of markers which, should they appear in an article, advertisement or slideshow, should be a warning to treat the rest of the content with a hefty pinch of salt. banging on about fines. yes; there is a big maximum fine. no, it’s unlikely to be enforced except for the most egregious cases of reckless negligence. the ico has never levied the maximum penalty for any breach ever. based on the evidence available, fines alone are not really a convincing justification for compliance. obsessing about consent. consent is only one of a number of possible legal basis for processing of personal data. it may not the most appropriate, desirable or “compliant” basis to select and insisting on consent where there is a statutory or contractual requirement for processing personal data; or where the individual has no real choice whether to give consent may result in “unfair processing” which could draw regulatory enforcement or litigation. focusing on infosec and infosec tech. information security (the “confidentiality and integrity” principle) is just 1 of 7 principles and doesn’t even start to fulfil obligations around rights or fairness. while it is important, focusing on infosec to the exclusion of the other principles is just as likely to cause serious problems as forgetting it altogether. claiming that encryption is a mandatory requirement. yes, it is mentioned specifically in a few places (recital 83, article 6, article 32, article 34) it is referenced as an example of a tool with which to mitigate risk. whether you need it depends on the “scope, nature and context” of processing. just having encryption will not make you “compliant” and not having encryption on all teh things will not mean that data is at risk of exposure. making it all about “compliance”. a finding of “compliance” in an audit is merely a snapshot of a point in time, assuming that the audit itself was sufficiently robust. a compliance-focused attitude often leads to ‘gaming the system’ (as anyone who has ever had an argument about scoping for pci-dss or iso2700x can attest). ticking boxes does not produce the intended outcome on its own -the paperwork must match reality. gdpr requires your reality to uphold principles, obligations, rights. if you’re not doing this in practice, no amount of audit reports, certificates or checklists will save you when it all goes wrong. think “maturity” and “assurance”, “quality” and “effectiveness” rather than “compliance” insisting that only lawyers can be dpos. there are some very good data protection lawyers out there in the wild, but an awfully large majority of lawyers who know almost nothing about privacy law. there are many experienced and competent data protection professionals who know privacy law inside-out but do not have a law degree. the only reason for insisting on having a lawyer as a data protection officer or dp lead is if the lawyer is *already* a dp specialist with business, communications & technical skills. the “lawyer” part is incidental. marketing gdpr stuff by breaching other laws (pecr) or in breach of dpa/gdpr itself (were you given a privacy notice about the use of your information for marketing purposes? is it a fair use of your personal data?) calling it the “general data protection regulations”. seriously, people. it’s regulation (eu) 2016/679, singular (even though there is a lot of it). ok, those are the “approach with caution” signs. but how to find good advice on gdpr? here’s some advice for spotting people who probably know what they’re talking about: a competent privacy practitioner will tell you there is no magic spell; time, effort, decision-making and resources will be required to adapt to gdpr requirements there is no single tool, audit framework, self-assessment template, cut-n-paste policy or off-the-shelf training module that will make you “compliant”. you need to address systems, process and culture at all layers and contexts. records management is just as significant as infosec (if not more so) it’s not about paperwork – it’s about upholding fundamental human rights and freedoms (ok, that last one might be a step too far for many dp pro.s, but it is significant both to the intent and the implementation of gdpr.) a few more handy tips for your privacy team lineup domain-specific knowledge is vital and valuable – but remember that specialists specialise, and so it is unlikely that someone who has only ever worked in one area of information governance (e.g. information security, records management) or context (hr, marketing, sales) will be able to address all of your gdpr needs. the same consideration applies for lawyers – commercial, contract and general counsel-type lawyers are probably not as familiar with privacy law as with their own areas of expertise. in summary, to find good gdpr advice, you should: get a rounded view consider risks to individuals’ privacy not just organisational impact instil and maintain privacy-aware culture and practices be deeply suspicious of any/all claims of one-stop/universal fixes just culture 2: risky behaviour published 2017-02-28 previously, i’ve introduced the concept of the “just culture” and explained the basic principle. in this blog post i will look at the types of behaviour that give rise to incidents and how, in a just culture, these would be addressed. hands up if you’ve ever done any of the following: politely held the door to your office open for a stranger without asking to see their id re-used a password emailed work to your personal account to work on outside the office mis-addressed an email, or mistakenly used cc rather than bcc did it seem like a good idea at the time? (you can lower your hands now, by the way) perhaps you were under pressure to get work done to a deadline, or maybe you couldn’t afford the cognitive effort of considering security policies at the time. these types of “incidents” occur every day, all over the place and in most cases they do not result in disaster – but one day, they could…and unfortunately, in most corporate cultures the blame will rest on the person who didn’t follow the policies. in a just culture, blame is not appropriate and punishment is only reserved for a minority of behaviours – those which were driven by malicious intent or deliberate and knowing recklessness. none of the activities listed above really fall into that category and so even if they did result in major data leakage, disruption or loss; should not be responded to with punitive action – especially if everyone is doing the same but getting away with it. the sysadmin who runs a private file-sharing server on the corporate network, or the manager who illegally snoops on their staff’s emails should be punished – not those who are just trying to get on with their jobs. most incidents arise from “risky behaviour” rather than malice or knowing recklessness. risky behaviour falls into two main categories: genuine error (see http://missinfogeek.net/human-error/ for some further thoughts on that) – such as mis-typing a name, confusing two similar-looking people, being taken in by a highly-convincing well-crafted scam site or email or unknowingly putting your security pass in the pocket that has a hole in the bottom underestimation or low prioritisation of the risks (perhaps due to conflicting imperatives – e.g. time pressure, budget constraints, performance goals) – this is where most risky behaviour occurs. these behaviours should not be treated the same way, for that would be unjust. in the case of 1), the appropriate response is consolation and a review of controls to identify whether there are any areas which could benefit from additional ‘sanity checks’ without making it too difficult for people to get their jobs done. humans are imperfect and any system or process that relies on 100% human accuracy is doomed to fail – this is a design fault, not the fault of the errant. the second type of behaviour is more challenging to mitigate, especially since human beings are generally rubbish at assessing risk on the fly. add in cognitive dissonance, conflicting priorities and ego and you end up with the greatest challenge of the just culture! explaining the reason that the behaviour is risky, pointing out the correct approach and issuing a friendly warning not to do it again (or else) is the appropriate and fair response. so how in general should risky behaviour be prevented? education is the foundation here – not just a single half-hour e-learning module once a year, but frequent and engaging discussion of infosec risks using real-life anecdotes, analogies, humour and encouraging input from all. on top of the education programme; there needs to be a candid look at business process, systems, procedure and tools – are they set up to make risky behaviour the path of least resistance or do they encourage careful thought and good habits? monitoring and correcting behaviour comes next and it is critical that this be done impartially and with as much vigour at senior levels than for front-line and junior staff. if the c-suite can flout policy with impunity then not only will you struggle to achieve a successful just culture, but you also have a gaping big hole in your security defences. a just culture relies on robust procedures, a series of corrective nudges and above all, consistency of responses in order to be effective. far too often, individuals are thrown to the wolves for simply getting unlucky – forced to use non-intuitive or badly-configured systems, under pressure from management above, with inadequate resources and insufficient training, they cut the same corners as they see everyone else doing – and pay the price of the organisation’s failures. next time: building a just culture in a pit of snakes* *something like that, anyway posts navigation 1 2 next cele theme by compete themes. warning - this site sets cookies! unfortunately, i am unable to disable some of the inbuilt tracking without killing the site content. tell me more reluctantly accept the cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. if you continue to use this website without changing your cookie settings or you click "accept" below then you are consenting to this. close

URL analysis for missinfogeek.net

http://missinfogeek.net/tea-sex-and-data/
http://missinfogeek.net/privacy-cookies/
http://missinfogeek.net/gdpr-millionaire/
http://missinfogeek.net/#main
http://missinfogeek.net/whos-in-control/
http://missinfogeek.net/category/breaches-and-incidents/
http://missinfogeek.net/2017/05/
http://missinfogeek.net/tag/incident-response/
http://missinfogeek.net/tag/infosec/
http://missinfogeek.net/tag/dcdp/
http://missinfogeek.net/tag/rant/
http://missinfogeek.net/articles/
http://missinfogeek.net/sample-page-2/
http://missinfogeek.net/verelox/
http://missinfogeek.net/gdpr-consent/
protecture.org.uk
ico.org.uk

Whois Information

Whois is a protocol that is access to registering information. You can reach when the website was registered, when it will be expire, what is contact details of the site with the following informations. In a nutshell, it includes these informations;

Domain Name: MISSINFOGEEK.NET
Registry Domain ID: 2000872961_DOMAIN_NET-VRSN
Registrar WHOIS Server: whois.easyspace.com
Registrar URL: http://www.easyspace.com
Updated Date: 2017-01-24T13:50:59Z
Creation Date: 2016-02-07T13:26:06Z
Registry Expiry Date: 2018-02-07T13:26:06Z
Registrar: EASYSPACE LTD.
Registrar IANA ID: 79
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +44.3707555066
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: NS.34SP.COM
Name Server: NS2.34SP.COM
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2017-09-08T06:50:47Z <<<

For more information on Whois status codes, please visit https://icann.org/epp

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.

  REGISTRAR EASYSPACE LTD.

SERVERS

  SERVER net.whois-servers.net

  ARGS domain =missinfogeek.net

  PORT 43

  TYPE domain

DOMAIN

  NAME missinfogeek.net

  CHANGED 2017-01-24

  CREATED 2016-02-07

STATUS
clientTransferProhibited https://icann.org/epp#clientTransferProhibited
clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited

NSERVER

  NS.34SP.COM 80.82.112.108

  NS2.34SP.COM 89.21.0.52

  REGISTERED yes

Mistakes

The following list shows you to spelling mistakes possible of the internet users for the website searched .