Recherche avancée

Sur d’autres sites (6121)

• Revision 34657 : lister les plugins non utilises (le glob() est pourri, qui fait mieux)

  23 janvier 2010, par fil@… — Log

  lister les plugins non utilises (le glob() est pourri, qui fait mieux)

• Your Essential SOC 2 Compliance Checklist

  11 mars, par Daniel Crough — Privacy, Security

  With cloud-hosted applications becoming the norm, organisations face increasing data security and compliance challenges. SOC 2 (System and Organisation Controls 2) provides a structured framework for addressing these challenges. Established by the American Institute of Certified Public Accountants (AICPA), SOC 2 has become a critical standard for demonstrating trustworthiness to clients and partners.

  A well-structured SOC 2 compliance checklist serves as your roadmap to successful audits and effective security practices. In this post, we’ll walk through the essential steps to achieve SOC 2 compliance and explain how proper analytics practices play a crucial role in maintaining this important certification.

  Download SOC2 Checklist

  

  What is SOC 2 compliance ?

  SOC 2 compliance applies to service organisations that handle sensitive customer data. While not mandatory, this certification builds significant trust with customers and partners.

  According to the AICPA, “SOC 2 reports are intended to meet the needs of a broad range of users that need detailed information and assurance about the controls at a service organisation relevant to security, availability, and processing integrity of the systems the service organisation uses to process users’ data and the confidentiality and privacy of the information processed by these systems.“

  At its core, SOC 2 helps organisations protect customer data through five fundamental principles : security, availability, processing integrity, confidentiality, and privacy.

  Think of it as a seal of approval that tells customers, “We take data protection seriously, and here’s the evidence.”

  Companies undergo SOC 2 audits to evaluate their compliance with these standards. During these audits, independent auditors assess internal controls over data security, availability, processing integrity, confidentiality, and privacy.

  What is a SOC 2 compliance checklist ?

  A SOC 2 compliance checklist is a comprehensive guide that outlines all the necessary steps and controls an organisation needs to implement to achieve SOC 2 certification. It covers essential areas including :

  • Security policies and procedures
  • Access control measures
  • Risk assessment protocols
  • Incident response plans
  • Disaster recovery procedures
  • Vendor management practices
  • Data encryption standards
  • Network security controls

  SOC 2 compliance checklist benefits

  A structured SOC 2 compliance checklist offers several significant advantages :

  Preparedness

  Preparing for a SOC 2 examination involves many complex elements. A checklist provides a clear, structured path, breaking the process into manageable tasks that ensure nothing is overlooked.

  Resource optimisation

  A comprehensive checklist reduces time spent identifying requirements, minimises costly mistakes and oversights, and enables more precise budget planning for the compliance process.

  Better team alignment

  A SOC 2 checklist establishes clear responsibilities for team members and maintains consistent understanding across all departments, helping align internal processes with industry standards.

  Risk reduction

  Following a SOC 2 compliance checklist significantly reduces the risk of compliance violations. Systematically reviewing internal controls provides opportunities to catch security gaps early, mitigating the risk of data breaches and unauthorised access.

  Audit readiness

  A well-maintained checklist simplifies audit preparation, reduces stress during the audit process, and accelerates the certification timeline.

  Business growth

  A successful SOC 2 audit demonstrates your organisation’s commitment to data security, which can be decisive in winning new business, especially with enterprise clients who require this certification from their vendors.

  Challenges in implementing SOC 2

  Implementing SOC 2 presents several significant challenges :

  Time-intensive documentation

  Maintaining accurate records throughout the SOC 2 compliance process requires diligence and attention to detail. Many organisations struggle to compile comprehensive documentation of all controls, policies and procedures, leading to delays and increased costs.

  Incorrect scoping of the audit

  Misjudging the scope can result in unnecessary expenses and extended timelines. Including too many systems complicates the process and diverts resources from critical areas.

  Maintaining ongoing compliance

  After achieving initial compliance, continuous monitoring becomes essential but is often neglected. Regular internal control audits can be overwhelming, especially for smaller organisations without dedicated compliance teams.

  Resource constraints

  Many organisations lack sufficient resources to dedicate to compliance efforts. This limitation can lead to staff burnout or reliance on expensive external consultants.

  Employee resistance

  Staff members may view new security protocols as unnecessary hurdles. Employees who aren’t adequately trained on SOC 2 requirements might inadvertently compromise compliance efforts through improper data handling.

  Analytics and SOC 2 compliance : A critical relationship

  One often overlooked aspect of SOC 2 compliance is the handling of analytics data. User behaviour data collection directly impacts multiple Trust Service Criteria, particularly privacy and confidentiality.

  Why analytics matters for SOC 2

  Standard analytics platforms often collect significant amounts of personal data, creating potential compliance risks :

  1. Privacy concerns : Many analytics tools collect personal information without proper consent mechanisms
  2. Data ownership issues : When analytics data is processed on third-party servers, maintaining control becomes challenging
  3. Confidentiality risks : Analytics data might be shared with advertising networks or other third parties
  4. Processing integrity questions : When data is transformed or aggregated by third parties, verification becomes difficult

  How Matomo supports SOC 2 compliance

  

  Matomo’s privacy-first analytics approach directly addresses these concerns :

  1. Complete data ownership : With Matomo, all analytics data remains under your control, either on your own servers or in a dedicated cloud instance
  2. Consent management : Built-in tools for managing user consent align with privacy requirements
  3. Data minimisation : Configurable anonymisation features help reduce collection of sensitive personal data
  4. Transparency : Clear documentation of data flows supports audit requirements
  5. Configurable data retention : Set automated data deletion schedules to comply with your policies

  By implementing Matomo as part of your SOC 2 compliance strategy, you address key requirements while maintaining the valuable insights your organisation needs for growth.

  Conclusion

  A SOC 2 compliance checklist helps organisations meet critical security and privacy standards. By taking a methodical approach to compliance and implementing privacy-respecting analytics, you can build trust with customers while protecting sensitive data.

  Start your 21-day free trial — no credit card needed.

• Parsing The Clue Chronicles

  30 décembre 2018, par Multimedia Mike — Game Hacking

  A long time ago, I procured a 1999 game called Clue Chronicles : Fatal Illusion, based on the classic board game Clue, a.k.a. Cluedo. At the time, I was big into collecting old, unloved PC games so that I could research obscure multimedia formats.

  
  
  

  Surveying the 3 CD-ROMs contained in the box packaging revealed only Smacker (SMK) videos for full motion video which was nothing new to me or the multimedia hacking community at the time. Studying the mix of data formats present on the discs, I found a selection of straightforward formats such as WAV for audio and BMP for still images. I generally find myself more fascinated by how computer games are constructed rather than by playing them, and this mix of files has always triggered a strong “I could implement a new engine for this !” feeling in me, perhaps as part of the ScummVM project which already provides the core infrastructure for reimplementing engines for 2D adventure games.

  Tying all of the assets together is a custom high-level programming language. I have touched on this before in a blog post over a decade ago. The scripts are in a series of files bearing the extension .ini (usually reserved for configuration scripts, but we’ll let that slide). A representative sample of such a script can be found here :

  clue-chronicles-scarlet-1.txt

  What Is This Language ?
  At the time I first analyzed this language, I was still primarily a C/C++-minded programmer, with a decent amount of Perl experience as a high level language, and had just started to explore Python. I assessed this language to be “mildly object oriented with C++-type comments (‘//’) and reliant upon a number of implicit library functions”. Other people saw other properties. When I look at it nowadays, it reminds me a bit more of JavaScript than C++. I think it’s sort of a Rorschach test for programming languages.

  Strangely, I sort of had this fear that I would put a lot of effort into figuring out how to parse out the language only for someone to come along and point out that it’s a well-known yet academic language that already has a great deal of supporting code and libraries available as open source. Google for “spanish dolphins far side comic” for an illustration of the feeling this would leave me with.

  It doesn’t matter in the end. Even if such libraries exist, how easy would they be to integrate into something like ScummVM ? Time to focus on a workable approach to understanding and processing the format.

  Problem Scope
  So I set about to see if I can write a program to parse the language seen in these INI files. Some questions :

  1. How large is the corpus of data that I need to be sure to support ?
  2. What parsing approach should I take ?
  3. What is the exact language format ?
  4. Other hidden challenges ?

  To figure out how large the data corpus is, I counted all of the INI files on all of the discs. There are 138 unique INI files between the 3 discs. However, there are 146 unique INI files after installation. This leads to a hidden challenge described a bit later.

  What parsing approach should I take ? I worried a bit too much that I might not be doing this the “right” way. I’m trying to ignore doubts like this, like how “SQL Shame” blocked me on a task for a little while a few years ago as I concerned myself that I might not be using the purest, most elegant approach to the problem. I know I covered language parsing a lot time ago in university computer science education and there is a lot of academic literature to the matter. But sometimes, you just have to charge in and experiment and prototype and see what falls out. In doing so, I expect to have a better understanding of the problems that need to solved and the right questions to ask, not unlike that time that I wrote a continuous integration system from scratch because I didn’t actually know that “continuous integration” was the keyword I needed.

  Next, what is the exact language format ? I realized that parsing the language isn’t the first and foremost problem here– I need to know exactly what the language is. I need to know what the grammar are keywords are. In essence, I need to reverse engineer the language before I write a proper parser for it. I guess that fits in nicely with the historical aim of this blog (reverse engineering).

  Now, about the hidden challenges– I mentioned that there are 8 more INI files after the game installs itself. Okay, so what’s the big deal ? For some reason, all of the INI files are in plaintext on the CD-ROM but get compressed (apparently, according to file size ratios) when installed to the hard drive. This includes those 8 extra INI files. I thought to look inside the CAB installation archive file on the CD-ROM and the files were there… but all in compressed form. I suspect that one of the files forms the “root” of the program and is the launching point for the game.

  Parsing Approach
  I took a stab at parsing an INI file. My approach was to first perform lexical analysis on the file and create a list of 4 types : symbols, numbers, strings, and language elements ([]{}()=., :). Apparently, this is the kind of thing that Lex/Flex are good at. This prototyping tool is written in Python, but when I port this to ScummVM, it might be useful to call upon the services of Lex/Flex, or another lexical analyzer, for there are many. I have a feeling it will be easier to use better tools when I understand the full structure of the language based on the data available.
  
  The purpose of this tool is to explore all the possibilities of the existing corpus of INI files. To that end, I ran all 138 of the plaintext files through it, collected all of the symbols, and massaged the results, assuming that the symbols that occurred most frequently are probably core language features. These are all the symbols which occur more than 1000 times among all the scripts :

     6248 false
     5734 looping
     4390 scripts
     3877 layer
     3423 sequentialscript
     3408 setactive
     3360 file
     3257 thescreen
     3239 true
     3008 autoplay
     2914 offset
     2599 transparent
     2441 text
     2361 caption
     2276 add
     2205 ge
     2197 smackanimation
     2196 graphicscript
     2196 graphic
     1977 setstate
     1642 state
     1611 skippable
     1576 desc
     1413 delayscript
     1298 script
     1267 seconds
     1019 rect
  

  About That Compression
  I have sorted out at least these few details of the compression :

  bytes 0-3    "COMP" (a pretty strong sign that this is, in fact, compressed data)
  bytes 4-11   unknown
  bytes 12-15  size of uncompressed data
  bytes 16-19  size of compressed data (filesize - 20)
  bytes 20-    compressed payload
  

  The compression ratios are on the same order of gzip. I was hoping that it was stock zlib data. However, I have been unable to prove this. I wrote a Python script that scrubbed through the first 100 bytes of payload data and tried to get Python’s zlib.decompress to initialize– no luck. It’s frustrating to know that I’ll have to reverse engineer a compression algorithm that deals with just 8 total text files if I want to see this effort through to fruition.

  Update, January 15, 2019
  Some folks expressed interest in trying to sort out the details of the compression format. So I have posted a followup in which I post some samples and go into deeper details about things I have tried :

  Reverse Engineering Clue Chronicles Compression

  The post Parsing The Clue Chronicles first appeared on Breaking Eggs And Making Omelettes.